Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
On Fri, Dec 18, 2015 at 12:13 AM, Alan Stern wrote: > On Wed, 16 Dec 2015, Rob Herring wrote: > >> On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote: >> > On Monday 14 December 2015 15:26:11 Peter Chen wrote: >> >> Hi all, >> >> >> >> There is a known issue that the USB code can't handle USB HUB's >> >> external pins well, in that case, it may cause some onboard >> >> USB HUBs can't work since their PHY's clock or reset pin needs to >> >> operate. >> >> >> >> The user reported this issue at below: >> >> http://www.spinics.net/lists/linux-usb/msg131502.html >> >> >> >> In this patch set, I add a generic onboard USB HUB driver to >> >> handle this problem, the external signals will be configured >> >> before usb controller's initialization, it much likes we did >> >> it at board code before. >> >> >> >> The user needs to add this generic hub node at dts to support it. >> >> >> >> @The udoo users, help to test please. >> > >> > I still think need to do this properly by representing the hub >> > device as a USB device, using power sequencing code like MMC does. >> >> I agree on doing it properly, but am not sure that pwrseq binding for >> MMC is proper. The pwrseq binding is fairly limited and working around >> the driver model IMO. Hubs may also need I2C setup which I don't think >> could be done generically other than some defined sequence of i2c >> transactions. The current project I'm working on needs to use I2C to >> configure the hub to use HSIC mode for example. I really think we need >> a pre-probe driver hook to handle this. That would allow device >> specific setup to live in the driver. >> >> Perhaps a more simple approach would be just forcing driver probe if a >> DT node is present. I'm not all that familiar with USB drivers, but >> presumably there is some setup before probe like setting the USB >> device address. We'd have to allow doing that later during probe. > > It's not clear (to me, anyway) how this is meant to work. USB is a > completely discoverable bus: There is no way to represent devices > statically; they have to be discovered. But a device can't be > discovered unless it is functional, so if an onboard hub (or any other > sort of USB device) requires power, clocks, or something similar in > order to function, it won't be discovered. There won't be any device > structure to probe, and "forcing driver probe" won't accomplish > anything. > > It seems to me that the only way something like this could be made to > work is if the necessary actions are keyed off the host controller (and > in particular, _not_ the hub driver), presumably at the time the > controller is probed. The reason why I put the code at hub driver is the onboard USB device may be at 2nd level hub, at hub driver, we can know all devices under this level hub. > With anything else, you run the risk that the > necessary resources won't get enabled before they are needed. > Sorry, I can't understand what you mean -- BR, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
On Thu, Dec 17, 2015 at 9:49 PM, Rob Herring wrote:
> On Wed, Dec 16, 2015 at 8:31 PM, Peter Chen wrote:
>> On Thu, Dec 17, 2015 at 12:13:07AM +0100, Arnd Bergmann wrote:
>>> On Wednesday 16 December 2015 16:59:39 Rob Herring wrote:
>>> > On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote:
>>> > > On Monday 14 December 2015 15:26:11 Peter Chen wrote:
>>> >
>>> > I agree on doing it properly, but am not sure that pwrseq binding for
>>> > MMC is proper. The pwrseq binding is fairly limited and working around
>>> > the driver model IMO. Hubs may also need I2C setup which I don't think
>>> > could be done generically other than some defined sequence of i2c
>>> > transactions. The current project I'm working on needs to use I2C to
>>> > configure the hub to use HSIC mode for example. I really think we need
>>> > a pre-probe driver hook to handle this. That would allow device
>>> > specific setup to live in the driver.
>>> >
>>> > Perhaps a more simple approach would be just forcing driver probe if a
>>> > DT node is present. I'm not all that familiar with USB drivers, but
>>> > presumably there is some setup before probe like setting the USB
>>> > device address. We'd have to allow doing that later during probe.
>>>
>>> Yes, good idea. I was also advocating that approach for MMC at some
>>> point, but the power sequencing made it in the end.
>>>
>>
>> Currently, my design is much like Rob proposal's. I will populate all
>> children device under HUB's node (controller = 1st level hub), and
>> each special onboard USB device needs a platform driver, it can be
>> probed according to compatible string, and at its probe, it can register
>> itself as usb device if needed, and handle properties described at
>> its node. Sample code like below:
>
> It is not like my proposal because I don't think the design should be
> using a platform driver.
>
FSL email is migrating with NXP's, it is unavailable now, I use my
gmail account.
If I understand correct, you would like use current USB class driver to handle
its related device. Yes, it can work only the device can be discovered without
any pre-setup, like reset, clock setting, etc. The related class driver's probe
is only called when this kinds of classes (hid, mass storage, ethernet, etc)
is discovered by USB bus.
Besides this, we need pre-setup code to let the USB device can be discovered
if needed. There is no place to put this pre-setup code at related
class driver,
->probe will be called after discovered, at its init, we have no
struct device *,
even we can create an API for this purpose, and call it at its parent's driver,
this class driver may be not loaded at all.
If not use platform driver, we had to use the way MMC power code does that
is have this pre-setup code as library, and build together with USB core.
>> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>> b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>> index 8263fc1..7451f7d 100644
>> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>> @@ -590,6 +590,16 @@
>> &usbh1 {
>> vbus-supply = <®_usb_h1_vbus>;
>> status = "okay";
>> +
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + hub: usb2415@01 {
>> + compatible = "generic-onboard-hub";
>
> Please follow the already defined naming scheme for USB devices.
>
> Rob
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
BR,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I2C eeprom compatibles? (was Re: [PATCH/RFC 03/19] ARM: shmobile: gose: add i2c2 bus to device tree)
On Fri, Dec 18, 2015 at 12:02:39PM +0900, Simon Horman wrote:
> On Mon, Dec 14, 2015 at 10:39:47AM +0100, Geert Uytterhoeven wrote:
> > On Mon, Dec 14, 2015 at 8:11 AM, Wolfram Sang wrote:
> > >> > >+ eeprom@50 {
> > >> > >+ compatible = "renesas,24c02";
> > >> >
> > >> >This is not a valid value -- the Renesas chip model is different
> > >> > from 24c02.
> > >>
> > >> I copied this value from r8a7791.dtsi.
> > >>
> > >> Looking at the schematic for gose (v100), koelsch (rev024) and porter
> > >> (v300)
> > >> I see the following "R1EX24002ATAS0G#U0". Shall we update r8a7791 and
> > >> this patch to "renesas,24002" or leave things as is?
> > >
> > > I wouldn't like to update the at24 driver with all namings from all
> > > vendors for chips which in large cases are simple 24c02 devices.
> > >
> > > So, if Sergei insists on the change, I'd propose
> > >
> > > compatible = "renesas,24002", "24c02";
> >
> > "renesas,r1ex24002"?
> >
> > I don't think the "A" is relevant (<= 64 is A, >= 128 is B).
> >
> > http://www.renesas.com/products/memory/eeprom/product_selector.jsp
>
> Thanks.
>
> It seems to me that we have some consensus around:
>
> compatible = "renesas,r1ex24002", "24c02";
Thinking again, "generic,24c02" or "generic-24c02" could also be an
option.
> Should this be added to Documentation/devicetree/bindings/eeprom/eeprom.txt ?
> Or documented elsewhere?
Probably we need a DT maintainers advice here? I don't mind vendor
specific compatibles being documented, but I'm reluctant to add all
these compatibles for the myriads of I2C eeproms to the at24 driver. 99%
are covered by the generic case.
Adding DT to CC.
Thanks,
Wolfram
signature.asc
Description: Digital signature
Re: [PATCH v3 0/2] ARM64: Enable SP805 WDT support for FSL LS2080A
Hi Rob, Mark, On Tue, Dec 15, 2015 at 8:00 PM, Bhupesh Sharma wrote: > This is the v3 of patchset which adds the support for SP805 WDT on FSL LS2080A > and also adds the missing documentation of SP805 WDT device-tree bindings. Any comments on this version, or does it seems fine for integration into the arm-soc tree. Regards, Bhupesh > > Rebased against arm-soc/next/dt > > Changes since v2: > (v2 can be viewed here: > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/463141) > - Addressed Rob's comments regarding the second mandatory CLK source's > (WDOGCLK) name in the bindings. > > Changes since v1: > (v1 can be viewed here: > http://www.spinics.net/lists/devicetree/msg102487.html) > > - Addressed Rob and Mark's comments regarding the mandatory CLK sources > - Removed interrupt property from the bindings for now (as discussed > with Mark on IRC) till Will's patch proceeds further and enables > handling the WDOG interrupts for each core connected to the same PPI > line > (http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/391616.html) > > Bhupesh Sharma (2): > Documentation: DT: Add entry for ARM SP805-WDT > dts/ls2080a: Update DTSI to add support of SP805 WDT > > .../devicetree/bindings/watchdog/sp805-wdt.txt | 29 ++ > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 56 > > 2 files changed, 85 insertions(+) > create mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt.txt > > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/5] ARM: dts: DRA7: add entry for qspi mmap region
On 12/18/2015 12:15 AM, Tony Lindgren wrote: > * Rob Herring [151211 07:10]: >> On Fri, Dec 11, 2015 at 09:39:59AM +0530, Vignesh R wrote: >>> Add qspi memory mapped region entries for DRA7xx based SoCs. Also, >>> update the binding documents for the controller to document this change. >>> >>> Signed-off-by: Vignesh R >> >> Acked-by: Rob Herring > > Vignes, are patches 4 and 5 safe to apply separately already or > do things break if we do that? Yes, 4 and 5 can be applied separately w/o driver changes. -- Regards Vignesh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v02 0/2] ARM: DTS: am33xx/am437x: Use the new eDMA bindings
On Thu, Dec 17, 2015 at 09:48:44AM -0800, Tony Lindgren wrote: > * Peter Ujfalusi [151217 05:33]: > > Hi, > > > > Changes since v1: > > - Updated to use the non 16bit arrays [1] > > - send the two patch as a series > > > > [1] > > As it has been discussed earlier: > > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html > > > > the DT bindings has been changes compared to what we had in 4.4-rc1: the > > arrays > > now don't have the 16bit type. > > The changes are now merged to mainline and Vinod provided us a branch: > > > > git://git.infradead.org/users/vkoul/slave-dma.git fix/edma > > > > Which is based on 4.4-rc1 and only contains the two patch for changing the > > eDMA > > bindings. > > Great, I'll merge the fix/edma also into omap-for-v4.5/dt and apply > your two patches. FWIW, fix/edma is in Linu's tree now and should be in -rc6 Thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.
DT bindings for numa mapping of memory, cores and IOs.
Reviewed-by: Robert Richter
Signed-off-by: Ganapatrao Kulkarni
---
Documentation/devicetree/bindings/arm/numa.txt | 273 +
1 file changed, 273 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/numa.txt
diff --git a/Documentation/devicetree/bindings/arm/numa.txt
b/Documentation/devicetree/bindings/arm/numa.txt
new file mode 100644
index 000..5bd893e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/numa.txt
@@ -0,0 +1,273 @@
+==
+NUMA binding description.
+==
+
+==
+1 - Introduction
+==
+
+Systems employing a Non Uniform Memory Access (NUMA) architecture contain
+collections of hardware resources including processors, memory, and I/O buses,
+that comprise what is commonly known as a NUMA node.
+Processor accesses to memory within the local NUMA node is generally faster
+than processor accesses to memory outside of the local NUMA node.
+DT defines interfaces that allow the platform to convey NUMA node
+topology information to OS.
+
+==
+2 - numa-node-id
+==
+
+For the purpose of identification, each NUMA node is associated with a unique
+token known as a node id. For the purpose of this binding
+a node id is a 32-bit integer.
+
+A device node is associated with a NUMA node by the presence of a
+numa-node-id property which contains the node id of the device.
+
+Example:
+ /* numa node 0 */
+ numa-node-id = <0>;
+
+ /* numa node 1 */
+ numa-node-id = <1>;
+
+==
+3 - distance-map
+==
+
+The device tree node distance-map describes the relative
+distance(memory latency) between all numa nodes.
+
+- compatible : Should at least contain "numa-distance-map-v1".
+
+- distance-matrix
+ This property defines a matrix to describe the relative distances
+ between all numa nodes.
+ It is represented as a list of node pairs and their relative distance.
+
+ Note:
+ 1. Each entry represents distance from first node to second node.
+ The distance are equal in either direction.
+ 2. The distance from a node to self(local distance) is represented
+ with value 10 and all inter node distance should be represented with
+ value greater than 10.
+ 3. distance-matrix shold have entries in lexicographical ascending
+ order of nodes.
+ 4. There must be only one Device node distance-map and must reside in
the root node.
+
+Example:
+ 4 nodes connected in mesh/ring topology as below,
+
+ 0___20__1
+ | |
+ | |
+ 20 20
+ | |
+ | |
+ |___|
+ 3 20 2
+
+ if relative distance for each hop is 20,
+ then inter node distance would be,
+ 0 -> 1 = 20
+ 1 -> 2 = 20
+ 2 -> 3 = 20
+ 3 -> 0 = 20
+ 0 -> 2 = 40
+ 1 -> 3 = 40
+
+ and dt presentation for this distance matrix is,
+
+ distance-map {
+compatible = "numa-distance-map-v1";
+distance-matrix = <0 0 10>,
+ <0 1 20>,
+ <0 2 40>,
+ <0 3 20>,
+ <1 0 20>,
+ <1 1 10>,
+ <1 2 20>,
+ <1 3 40>,
+ <2 0 40>,
+ <2 1 20>,
+ <2 2 10>,
+ <2 3 20>,
+ <3 0 20>,
+ <3 1 40>,
+ <3 2 20>,
+ <3 3 10>;
+ };
+
+
+==
+4 - Example dts
+==
+
+2 sockets system consists of 2 boards connected through ccn bus and
+each board having one socket/soc of 8 cpus, memory and pci bus.
+
+ memory@00c
Re: [PATCH 0/7] ARM: shmobile: dtsi: Add SCIF fallback compatibility strings
On Mon, Dec 14, 2015 at 07:57:48PM +0100, Geert Uytterhoeven wrote: > Hi Simon, Magnus, > > This patch series adds fallback compatibility strings for SCIF and HSCIF > to the DTS files for R-Car Gen1, Gen2, and Gen3, as defined in > "[PATCH v3 02/27] serial: sh-sci: Add fallback compatibility strings" of > series "[PATCH v3 00/27] serial: sh-sci: External Clock Support". > This will allow the sh-sci driver to match on family-specific compatible > values to enable BGR support later. > > Note that fallback compatibility strings for SCIFA/SCIFB are not added > yet. > > Dependencies: > - This series is against renesas-devel-20151214-v4.4-rc5, > - It can be applied independently, as soon as the aforementioned DT > binding patch has been accepted, > - Later series depend on this: > - "[PATCH v3 00/12] ARM: shmobile: dtsi: Rename the serial port >clock to fck", > - "[PATCH v2 0/7] ARM: shmobile: dtsi: Add BRG support for (H)SCIF", > - "[PATCH v2 0/9] ARM: shmobile: dts: Enable SCIF_CLK frequency and >pins". I have marked this and the above series as deferred pending acceptance of the driver changes. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.
On Fri, Dec 18, 2015 at 12:37 AM, Mark Rutland wrote: > Hi, > > On Fri, Dec 11, 2015 at 08:11:07PM +0530, Ganapatrao Kulkarni wrote: >> On Fri, Dec 11, 2015 at 7:23 PM, Mark Rutland wrote: >> > Hi, >> > >> > On Tue, Nov 17, 2015 at 10:50:41PM +0530, Ganapatrao Kulkarni wrote: >> >> DT bindings for numa mapping of memory, cores and IOs. >> >> >> >> Reviewed-by: Robert Richter >> >> Signed-off-by: Ganapatrao Kulkarni >> > >> > Overall this looks good to me. However, I have a couple of concerns. >> thanks. > > [...] > >> >> +== >> >> +2 - numa-node-id >> >> +== >> >> +The device node property numa-node-id describes numa domains within a >> >> +machine. This property can be used in device nodes like cpu, memory, bus >> >> and >> >> +devices to map to respective numa nodes. >> >> + >> >> +numa-node-id property is a 32-bit integer which defines numa node id to >> >> which >> >> +this device node has numa domain association. >> > >> > I'd prefer if the above two paragraphs were replaced with: >> > >> > For the purpose of identification, each NUMA node is associated >> > with a unique token known as a node id. For the purpose of this >> > binding a node id is a 32-bit integer. >> > >> > A device node is associated with a NUMA node by the presence of >> > a numa-node-id property which contains the node id of the >> > device. >> ok, will do. > > [...] > >> >> +== >> >> +3 - distance-map >> >> +== >> >> + >> >> +The device tree node distance-map describes the relative >> >> +distance (memory latency) between all numa nodes. >> > >> > Is this not a combined approximation for latency and bandwidth? >> AFAIK, it is to represent inter-node memory access latency. >> > >> >> +- compatible : Should at least contain "numa,distance-map-v1". >> > >> > Please use "numa-distance-map-v1", as "numa" is not a vendor. >> ok >> > >> >> +- distance-matrix >> >> + This property defines a matrix to describe the relative distances >> >> + between all numa nodes. >> >> + It is represented as a list of node pairs and their relative distance. >> >> + >> >> + Note: >> >> + 1. Each entry represents distance from first node to second node. >> >> + 2. If both directions between 2 nodes have the same distance, only >> >> +one entry is required. >> > >> > I still don't understand what direction means in this context. Are there >> > systems (of any architecture) which don't have symmetric distances? >> > Which accesses does this apply differently to? >> > >> > Given that, I think that it might be best to explicitly call out >> > distances as being equal, and leave any directionality for a later >> > revision of the binding when we have some semantics for directionality. >> agreed, given that there is no know system to substantiate dual direction, >> let us not explicit about direction. > > Regarding your comment in [1], I was expecting a respin of this series > with the above comments addressed. I will not provide an ack until I've > seen that. sure, i will respin with the comments addressed. > > Additional concerns below also apply. > >> >> + 2. distance-matrix shold have entries in lexicographical ascending >> >> order of nodes. >> >> + 3. There must be only one Device node distance-map and must reside >> >> in the root node. >> >> + >> >> +Example: >> >> + 4 nodes connected in mesh/ring topology as below, >> >> + >> >> + 0___20__1 >> >> + | | >> >> + | | >> >> + 20| |20 >> >> + | | >> >> + | | >> >> + |___| >> >> + 3 20 2 >> >> + >> >> + if relative distance for each hop is 20, >> >> + then inter node distance would be for this topology will be, >> >> + 0 -> 1 = 20 >> >> + 1 -> 2 = 20 >> >> + 2 -> 3 = 20 >> >> + 3 -> 0 = 20 >> >> + 0 -> 2 = 40 >> >> + 1 -> 3 = 40 >> > >> > How is this scaled relative to a local access? >> this is based on representing local distance with 10 and >> all inter-node latency being represented as multiple of 10. >> >> > >> > Do we assume that a local access has value 1, e.g. each hop takes 20x a >> > local access in this example? >> The local distance is represented as 10, this is fixed and same as in ACPI. >> Inter-node distance can be any number greater than 10. >> this information can be added here to make it clear. > > This seems rather arbitrary. > > Why can we not define the local distance in the DT? I appreciate that > the value is hard-coded for ACPI, but we don'
[RESEND PATCH] mtd: mtk-nor: adjust sequence of trigger function and assignment function
Move write data register before excute command to avoid
missing first byte write to nor flash
Signed-off-by: Bayi Cheng
---
the previous patch didn't drop the Change-Id
---
drivers/mtd/spi-nor/mtk-quadspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
b/drivers/mtd/spi-nor/mtk-quadspi.c
index dd269650..04da971 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -272,10 +272,10 @@ static int mt8173_nor_write_single_byte(struct mt8173_nor
*mt8173_nor,
mt8173_nor_set_addr(mt8173_nor, addr);
for (i = 0; i < length; i++) {
+ writeb(*data++, mt8173_nor->base + MTK_NOR_WDATA_REG);
ret = mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_PIO_WR_CMD);
if (ret < 0)
return ret;
- writeb(*data++, mt8173_nor->base + MTK_NOR_WDATA_REG);
}
return 0;
}
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mtd: mtk-nor: adjust sequence of trigger function and assignment function
move write data register before excute command to avoid
missing first byte write to nor flash
Change-Id: Ie9d7ae30f9de1f3e976d2e1de5d8ee28837598c8
Signed-off-by: Bayi Cheng
---
drivers/mtd/spi-nor/mtk-quadspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c
b/drivers/mtd/spi-nor/mtk-quadspi.c
index dd269650..04da971 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -272,10 +272,10 @@ static int mt8173_nor_write_single_byte(struct mt8173_nor
*mt8173_nor,
mt8173_nor_set_addr(mt8173_nor, addr);
for (i = 0; i < length; i++) {
+ writeb(*data++, mt8173_nor->base + MTK_NOR_WDATA_REG);
ret = mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_PIO_WR_CMD);
if (ret < 0)
return ret;
- writeb(*data++, mt8173_nor->base + MTK_NOR_WDATA_REG);
}
return 0;
}
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next 2/5] mtd: spi-nor: fix Quad SPI mode support for Spansion, Micron and Macronix
On Mon, Dec 07, 2015 at 03:09:11PM +0100, Cyrille Pitchen wrote: > This patch reworks the support of Quad and Dual SPI protocols for Micron, > Spansion and Macronix Quad/Dual capable memories. Indeed, in the best > case, only Spansion memories are correctly supported by the current > spi-nor framework. ^^ Ah, so this is what I was struggling with at first. I agree that Micron looks broken. Quite possibly Macronix too. Unfortunately, I haven't had great test hardware for some of the quad modes. Especially not anything that supports generic SPI, and not completely on mainline. > 1 - Micron: > When their Quad SPI mode is enabled, Micron spi-nor memories expect all > commands to use the SPI 4-4-4 protocol. Also when the Dual SPI mode is > enabled, all commands must use the SPI 2-2-2 protocol. > > Before this patch, the spi-nor framework used to always enable the Quad > mode when the mode argument of spi_nor_scan() took the value SPI_NOR_QUAD. > That was not suited with drivers only supporting SPI 1-x-4 protocols but > not the 4-4-4 (e.g. the m25p80 driver). Also the SPI controller was not > notified about which SPI protocol to use to transfert command. We cannot > rely only on the op code: in Extended SPI mode the 0x6b command must use > the SPI 1-1-4 protocol whereas in Quad SPi mode the SPI 4-4-4 protocol > must be use instead. > > After this patch, the spi-nor framework uses the result of the > spi_nor_read_id() function to choose the right SPI protocol to be used. > If the reg_proto was set to SPI_PROTO_4_4_4, we already know that the Quad > SPI mode is already enabled and that the SPI controller supports the SPI > 4-4-4 protocol (otherwise it would have fail to read the JEDEC ID with the > 0xaf op code). For the very same reason, if the reg_proto was set to > SPI_PROTO_2_2_2, we already know that the Dual mode is already enabled and > that the SPI controller supports the SPI 2-2-2 protocol. > Otherwise we switch back to the Extended SPI protocol, which supports at > least the Fast Read commands: > - 1-1-1 (0x0b) > - Dual Output 1-1-2 (0x3b) > - Quad Output 1-1-4 (0x6b) > > We also safely set the number of dummy cycles to 8 for Fast Read commands > through the Volatile Configuration Register (VCR): some drivers (m25p80) > or SPI controllers only support a number of dummy cycles multiple of 8. > This number may have previouly been set to an unsupported value by an > early bootloader or at reset thanks to the Non-Volatile Configuration > Register. It's not clear to me how you're being safe with the dummy cycles at all. It seems like you're introducing new values that may be incompatible with drivers. That can be OK, but you have to give drivers a chance to opt-out... Maybe some kind of "host capability" flags? > Finally the XIP bit is always set in the VCR to disable the Continuous > Read mode as we don't want to care about mode cycles. > > 2 - Macronix: > When the QPI mode is enabled, all commands must use the SPI 4-4-4 protocol > and only the 0xeb op code is supported for Fast Read commands. > Before this patch, the spi-nor framework used to force the QPI mode but > used the 0x6b op code for Fast Read commands when the SPI controller > claims to support Quad SPI mode. > This patch uses the result of spi_nor_read_id() to guess whether the QPI > mode is both enable and supported by the SPI controller (otherwise it > would have failed to read the JEDEC ID with the 0xaf op code). > When the QPI mode is disabled, Macronix memories still support the > following Fast Read commands: > - 1-1-1 (0x0b) > - Dual Output 1-1-2 (0x3b) > - Quad Output 1-1-4 (0x6b) > So if the QPI mode has not already been enabled, there is not need to > enable it. We also avoid the 0xbb (Dual I/O 1-2-2) and 0xeb (Quad I/O > 1-4-4) op codes on purpose as we don't want to care about the value to set > in mode cycles not to enter the Continuous Read (Performance Enhance) > mode. > > As for Micron memories, the spi-nor framework now safely sets the number > of dummy cycles to 8 thanks to 2 volatile bits inside the Configuration > Register. > > 3 - Spansion: > As for Macronix, we avoid the 0xbb (Dual I/O 1-2-2) and 0xeb (Quad I/O > 1-4-4) op codes on purpose as we don't want to care about the value to set > in mode cycles not to enter in the Continuous Read mode. > > Besides, we only care about the Quad Enable bit inside the Configuration > Register (CR) when using Quad operations. In such a case, we first check > its state before trying to set it. Now we also notify the user about the > update of this non-volatile bit. > > We also check the Latency Code (LC) in CR to know the exact number of > dummy cycles to use when performing a Fast Read operation. Currently only > the 0x0b, 0x3b and 0x6b op codes are used to perform Fast Read operation > so the number of dummy cycles is always either 0 or 8. Hence no regression > should be introduced. > > Signed-off-by: Cyrille Pitchen > --- > drivers/mtd/spi-nor/spi-nor.c | 783 >
Re: [PATCH linux-next 1/5] mtd: spi-nor: properly detect the memory when it boots in Quad or Dual mode
(Hit send too early; a few more comments)
On Mon, Dec 07, 2015 at 03:09:10PM +0100, Cyrille Pitchen wrote:
> drivers/mtd/spi-nor/spi-nor.c | 52
> +++
> include/linux/mtd/spi-nor.h | 23 +--
> 2 files changed, 69 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 3b2460efc019..bf17736750c1 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -73,6 +73,11 @@ struct flash_info {
>
> #define JEDEC_MFR(info) ((info)->id[0])
>
> +struct read_id_config {
> + enum read_mode mode;
> + enum spi_protocol proto;
> +};
> +
> static const struct flash_info *spi_nor_match_id(const char *name);
>
> /*
> @@ -867,11 +872,16 @@ static const struct flash_info spi_nor_ids[] = {
> { },
> };
>
> -static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
> +static const struct flash_info *spi_nor_read_id(struct spi_nor *nor,
> + enum read_mode mode)
> {
> - int tmp;
> + int i, tmp;
> u8 id[SPI_NOR_MAX_ID_LEN];
> const struct flash_info *info;
> + static const struct read_id_config configs[] = {
> + {SPI_NOR_QUAD, SPI_PROTO_4_4_4},
> + {SPI_NOR_DUAL, SPI_PROTO_2_2_2}
> + };
>
> tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
> if (tmp < 0) {
> @@ -879,6 +889,34 @@ static const struct flash_info *spi_nor_read_id(struct
> spi_nor *nor)
> return ERR_PTR(tmp);
> }
>
> + /* Special case for Micron/Macronix qspi nor. */
> + if ((id[0] == 0xff && id[1] == 0xff && id[2] == 0xff) ||
> + (id[0] == 0x00 && id[1] == 0x00 && id[2] == 0x00))
Is this specified anywhere, or is this just a heuristic, to guess
whether we're getting valid IDs? Do we know anything about what opcodes
look like ...
> + for (i = 0; i < ARRAY_SIZE(configs); ++i) {
> + if (configs[i].mode != mode)
> + continue;
> +
> + /* Set this protocol for all commands. */
> + nor->reg_proto = configs[i].proto;
> + nor->read_proto = configs[i].proto;
> + nor->write_proto = configs[i].proto;
> + nor->erase_proto = configs[i].proto;
> +
> + /*
> + * Multiple I/O Read ID only returns the Manufacturer ID
> + * (1 byte) and the Device ID (2 bytes). So we reset the
> + * remaining bytes.
> + */
Ugh, does that mean we get different IDs returned via the different
modes? That sounds like a disaster. What about all the flash that we
need 5+ bytes to differentiate? Just be glad we haven't come across any
Micron or Macronix like that yet?
> + memset(id, 0, sizeof(id));
> + tmp = nor->read_reg(nor, SPINOR_OP_MIO_RDID, id, 3);
Hmm, so you're passing implicit configuration data via the
nor->reg_proto field. So, spi-nor drivers now have to read that field
during every read_reg() invocation? Seems like either this should be:
(a) a driver hook/callback, so we can just reconfigure a handful of
times or
(b) part of a parameter that gets passed as part of the function
signature
> + if (tmp < 0) {
> + dev_dbg(nor->dev,
> + "error %d reading JEDEC ID Multi I/O\n",
> + tmp);
> + return ERR_PTR(tmp);
> + }
> + }
> +
> for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
> info = &spi_nor_ids[tmp];
> if (info->id_len) {
[...]
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next 1/5] mtd: spi-nor: properly detect the memory when it boots in Quad or Dual mode
Hi Cyrille,
On Mon, Dec 07, 2015 at 03:09:10PM +0100, Cyrille Pitchen wrote:
> The quad (or dual) mode of a spi-nor memory may be enabled at boot time by
> non-volatile bits in some setting register. Also such a mode may have
> already been enabled at early stage by some boot loader.
>
> Hence, we should not guess the spi-nor memory is always configured for the
> regular SPI 1-1-1 protocol.
>
> Micron and Macronix memories, once their Quad (or dual for Micron) mode
> enabled, no longer process the regular JEDEC Read ID (0x9f) command but
> instead reply to a new command: JEDEC Read ID Multiple I/O (0xaf).
> Besides, in Quad mode both memory manufacturers expect ALL commands to
> use the SPI 4-4-4 protocol. For Micron memories, enabling their Dual mode
> implies to use the SPI 2-2-2 protocol for ALL commands.
>
> Signed-off-by: Cyrille Pitchen
> ---
> drivers/mtd/spi-nor/spi-nor.c | 52
> +++
> include/linux/mtd/spi-nor.h | 23 +--
> 2 files changed, 69 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 3b2460efc019..bf17736750c1 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -73,6 +73,11 @@ struct flash_info {
>
> #define JEDEC_MFR(info) ((info)->id[0])
>
> +struct read_id_config {
> + enum read_mode mode;
> + enum spi_protocol proto;
> +};
> +
> static const struct flash_info *spi_nor_match_id(const char *name);
>
> /*
> @@ -867,11 +872,16 @@ static const struct flash_info spi_nor_ids[] = {
> { },
> };
>
> -static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
> +static const struct flash_info *spi_nor_read_id(struct spi_nor *nor,
> + enum read_mode mode)
It's unclear what you're trying to do with the 'read_mode' enum now.
(Admittedly it may not be clear in the current code either, given the
confusion we already have over Micron support.)
Would you care to document it better?
> {
> - int tmp;
> + int i, tmp;
> u8 id[SPI_NOR_MAX_ID_LEN];
> const struct flash_info *info;
> + static const struct read_id_config configs[] = {
> + {SPI_NOR_QUAD, SPI_PROTO_4_4_4},
> + {SPI_NOR_DUAL, SPI_PROTO_2_2_2}
> + };
>
> tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
> if (tmp < 0) {
> @@ -879,6 +889,34 @@ static const struct flash_info *spi_nor_read_id(struct
> spi_nor *nor)
> return ERR_PTR(tmp);
> }
>
> + /* Special case for Micron/Macronix qspi nor. */
> + if ((id[0] == 0xff && id[1] == 0xff && id[2] == 0xff) ||
> + (id[0] == 0x00 && id[1] == 0x00 && id[2] == 0x00))
> + for (i = 0; i < ARRAY_SIZE(configs); ++i) {
> + if (configs[i].mode != mode)
> + continue;
> +
> + /* Set this protocol for all commands. */
> + nor->reg_proto = configs[i].proto;
> + nor->read_proto = configs[i].proto;
> + nor->write_proto = configs[i].proto;
> + nor->erase_proto = configs[i].proto;
Are these all fully independent? Do we really need 4 fields for this?
> +
> + /*
> + * Multiple I/O Read ID only returns the Manufacturer ID
> + * (1 byte) and the Device ID (2 bytes). So we reset the
> + * remaining bytes.
> + */
> + memset(id, 0, sizeof(id));
> + tmp = nor->read_reg(nor, SPINOR_OP_MIO_RDID, id, 3);
> + if (tmp < 0) {
> + dev_dbg(nor->dev,
> + "error %d reading JEDEC ID Multi I/O\n",
> + tmp);
> + return ERR_PTR(tmp);
> + }
> + }
> +
> for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
> info = &spi_nor_ids[tmp];
> if (info->id_len) {
> @@ -1178,11 +1216,17 @@ int spi_nor_scan(struct spi_nor *nor, const char
> *name, enum read_mode mode)
> if (ret)
> return ret;
>
> + /* Reset SPI protocol for all commands */
> + nor->erase_proto = SPI_PROTO_1_1_1;
> + nor->read_proto = SPI_PROTO_1_1_1;
> + nor->write_proto = SPI_PROTO_1_1_1;
> + nor->reg_proto = SPI_PROTO_1_1_1;
> +
> if (name)
> info = spi_nor_match_id(name);
> /* Try to auto-detect if chip name wasn't specified or not found */
> if (!info)
> - info = spi_nor_read_id(nor);
> + info = spi_nor_read_id(nor, mode);
> if (IS_ERR_OR_NULL(info))
> return -ENOENT;
>
> @@ -1193,7 +1237,7 @@ int spi_nor_
Re: [PATCH v1 1/6] ARM: dts: fix the correct pinctrl control for rk3036
Heiko,
在 2015年12月18日 07:28, Heiko Stübner 写道:
Am Donnerstag, 17. Dezember 2015, 22:21:47 schrieb Caesar Wang:
The pinctrl gpio pull up/down is incorrect since the rk3036 SoCs
can't set the status in the internal.
We should keep the default status for enable the gpio status,
In fact, the pull_none is the disable the gpio pull up/down.
Signed-off-by: Xing Zheng
Signed-off-by: Caesar Wang
From the signed-off-by's I guess this change was created by Xing (author),
right?
The original patch:
- pcfg_pull_up: pcfg-pull-up {
- bias-pull-up;
- };
-
- pcfg_pull_down: pcfg-pull-down {
- bias-pull-down;
+ pcfg_pull_default: pcfg_pull_default {
+ bias-pull-pin-default;
I'm re-writing the patch to fit the others.
Yep, the seem should change commit author as the
Signed-off-by: Xing Zheng
Heiko
---
arch/arm/boot/dts/rk3036.dtsi | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index f8758bf..620e6e0 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -427,12 +427,8 @@
#interrupt-cells = <2>;
};
- pcfg_pull_up: pcfg-pull-up {
- bias-pull-up;
- };
-
- pcfg_pull_down: pcfg-pull-down {
- bias-pull-down;
+ pcfg_pull_default: pcfg_pull_default {
+ bias-pull-pin-default;
};
pcfg_pull_none: pcfg-pull-none {
@@ -473,18 +469,18 @@
};
emmc_cmd: emmc-cmd {
- rockchip,pins = <2 1 RK_FUNC_2 &pcfg_pull_none>;
+ rockchip,pins = <2 1 RK_FUNC_2
&pcfg_pull_default>;
};
emmc_bus8: emmc-bus8 {
- rockchip,pins = <1 24 RK_FUNC_2
&pcfg_pull_none>,
- <1 25 RK_FUNC_2
&pcfg_pull_none>,
- <1 26 RK_FUNC_2
&pcfg_pull_none>,
- <1 27 RK_FUNC_2
&pcfg_pull_none>,
- <1 28 RK_FUNC_2
&pcfg_pull_none>,
- <1 29 RK_FUNC_2
&pcfg_pull_none>,
- <1 30 RK_FUNC_2
&pcfg_pull_none>,
- <1 31 RK_FUNC_2
&pcfg_pull_none>;
+ rockchip,pins = <1 24 RK_FUNC_2
&pcfg_pull_default>,
+ <1 25 RK_FUNC_2
&pcfg_pull_default>,
+ <1 26 RK_FUNC_2
&pcfg_pull_default>,
+ <1 27 RK_FUNC_2
&pcfg_pull_default>,
+ <1 28 RK_FUNC_2
&pcfg_pull_default>,
+ <1 29 RK_FUNC_2
&pcfg_pull_default>,
+ <1 30 RK_FUNC_2
&pcfg_pull_default>,
+ <1 31 RK_FUNC_2
&pcfg_pull_default>;
};
};
@@ -522,12 +518,12 @@
uart0 {
uart0_xfer: uart0-xfer {
- rockchip,pins = <0 16 RK_FUNC_1 &pcfg_pull_up>,
+ rockchip,pins = <0 16 RK_FUNC_1
&pcfg_pull_default>,
<0 17 RK_FUNC_1
&pcfg_pull_none>;
};
uart0_cts: uart0-cts {
- rockchip,pins = <0 18 RK_FUNC_1 &pcfg_pull_up>;
+ rockchip,pins = <0 18 RK_FUNC_1
&pcfg_pull_default>;
};
uart0_rts: uart0-rts {
@@ -537,7 +533,7 @@
uart1 {
uart1_xfer: uart1-xfer {
- rockchip,pins = <2 22 RK_FUNC_1
&pcfg_pull_none>,
+ rockchip,pins = <2 22 RK_FUNC_1
&pcfg_pull_default>,
<2 23 RK_FUNC_1
&pcfg_pull_none>;
};
/* no rts / cts for uart1 */
@@ -545,7 +541,7 @@
uart2 {
uart2_xfer: uart2-xfer {
- rockchip,pins = <1 18 RK_FUNC_2
&pcfg_pull_none>,
+ rockchip,pins = <1 18 RK_FUNC_2
&pcfg_pull_default>,
<1 19 RK_FUNC_2
&pcfg_pull_none>;
};
/* no rts / cts for uart2 */
___
Linux-
Re: [PATCH v4 05/20] PM / devfreq: Add new passive governor
On 2015년 12월 14일 18:04, MyungJoo Ham wrote:
>>
>> This patch adds the new passive governor for DEVFREQ framework. The
>> following
>> governors are already present and used for DVFS (Dynamic Voltage and
>> Frequency
>> Scaling) drivers. The following governors are independently used for one
>> device
>> driver which don't give the influence to other device drviers and also don't
>> receive the effect from other device drivers.
>> - ondemand / performance / powersave / userspace
>>
>> The passive governor depends on operation of parent driver with specific
>> governos extremely and is not able to decide the new frequency by oneself.
>> According to the decided new frequency of parent driver with governor,
>> the passive governor uses it to decide the appropriate frequency for own
>> device driver. The passive governor must need the following information
>> from device tree:
>> - the source clock and OPP tables
>> - the instance of parent device
>>
>> For exameple,
>> there are one more devfreq device drivers which need to change their source
>> clock according to their utilization on runtime. But, they share the same
>> power line (e.g., regulator). So, specific device driver is operated as
>> parent
>> with ondemand governor and then the rest device driver with passive governor
>> is influenced by parent device.
>>
>> Suggested-by: Myungjoo Ham
>> Signed-off-by: Chanwoo Choi
>> [linux.amoon: Tested on Odroid U3]
>> Tested-by: Anand Moon
>> ---
>> drivers/devfreq/Kconfig| 9
>> drivers/devfreq/Makefile | 1 +
>> drivers/devfreq/devfreq.c | 47
>> drivers/devfreq/governor_passive.c | 108
>> +
>> include/linux/devfreq.h| 15 ++
>> 5 files changed, 180 insertions(+)
>> create mode 100644 drivers/devfreq/governor_passive.c
>>
>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>> index 55ec774f794c..d03f635a93e1 100644
>> --- a/drivers/devfreq/Kconfig
>> +++ b/drivers/devfreq/Kconfig
>> @@ -64,6 +64,15 @@ config DEVFREQ_GOV_USERSPACE
>>Otherwise, the governor does not change the frequnecy
>>given at the initialization.
>>
>> +config DEVFREQ_GOV_PASSIVE
>> +tristate "Passive"
>> +help
>> + Sets the frequency by other governors (simple_ondemand, performance,
>> + powersave, usersapce) of a parent devfreq device. This governor
>> + always has the dependency on the chosen frequency from paired
>> + governor. This governor does not change the frequency by oneself
>> + through sysfs entry.
>
> Sets the frequency based on the frequency of its parent devfreq
> device. This governor does not change the frequency by itself
> through sysfs entries.
OK. I'll modify it.
>
>> +
>> comment "DEVFREQ Drivers"
>>
>> config ARM_EXYNOS_BUS_DEVFREQ
>> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
>> index 375ebbb4fcfb..f81c313b4b79 100644
>> --- a/drivers/devfreq/Makefile
>> +++ b/drivers/devfreq/Makefile
> []
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index 984c5e9e7bdd..15e58779e4c0 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -190,6 +190,31 @@ static struct devfreq_governor
>> *find_devfreq_governor(const char *name)
>>
>> /* Load monitoring helper functions for governors use */
>>
>> +static int update_devfreq_passive(struct devfreq *devfreq, unsigned long
>> freq)
>> +{
>> +struct devfreq *passive;
>> +unsigned long rate;
>> +int ret;
>> +
>> +list_for_each_entry(passive, &devfreq->passive_dev_list, passive_node) {
>> +if (!passive->governor)
>> +continue;
>> +rate = freq;
>> +
>> +ret = passive->governor->get_target_freq(passive, &rate);
>> +if (ret)
>> +return ret;
>> +
>> +ret = passive->profile->target(passive->dev.parent, &rate, 0);
>> +if (ret)
>> +return ret;
>> +
>> +passive->previous_freq = rate;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> /**
>> * update_devfreq() - Reevaluate the device and configure frequency.
>> * @devfreq:the devfreq instance.
>> @@ -233,10 +258,18 @@ int update_devfreq(struct devfreq *devfreq)
>> flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
>> }
>>
>> +if (!list_empty(&devfreq->passive_dev_list)
>> +&& devfreq->previous_freq > freq)
>> +update_devfreq_passive(devfreq, freq);
>> +
>
> Could you please comment somewhere appropriate
> that the dependent is going to be changed
> before its parent if the frequency is going down.
> (and after if going up)
> And state why as well.
I use the DEVFREQ_TRANSITION_NOTIFIER instead of this implementation.
>
> And, is this viable universally?
>
>> err = devfreq->profile->target(devfreq->dev.parent, &freq, flags);
>
Re: [PATCH v4] extcon: add Maxim MAX3355 driver
Hi Sergei,
Except for just one comment below, Looks good to me.
Acked-by: Chanwoo Choi
I'll wait for a few days to get the review from DT maintainer
before applying it on extcon-next branch.
On 2015년 12월 18일 07:47, Sergei Shtylyov wrote:
> Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
> enable a system with an integrated USB OTG dual-role transceiver to
> function as an USB OTG dual-role device. In addition to sensing/controlling
> Vbus, the chip also passes thru the ID signal from the USB OTG connector.
> On some Renesas boards, this signal is just fed into the SoC thru a GPIO
> pin -- there's no real OTG controller, only host and gadget USB controllers
> sharing the same USB bus; however, we'd like to allow host or gadget
> drivers to be loaded depending on the cable type, hence the need for the
> MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
> (however, we aren't currently interested in them), the OFFVBUS# signal is
> controlled by the host controllers, there's also the SHDN# signal wired to
> a GPIO, it should be driven high for the normal operation.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
>
> Changes in version 4:
> - stopped calling kstrdup() for the device name;
> - removed unneeded 'owner' field initializer;
> - moved devm_extcon_allocate() call further down in the probe() method;
> - extended the driver copyright;
> - indented the continuation lines in the binding document.
>
> Changes in version 3:
> - reformatted the change log.
>
> Changes in version 2:
> - added the USB gadget cable support;
> - added the remove() driver method which drives SHDN# GPIO low to save power;
> - dropped vendor prefix from the ID GPIO property name;
> - changed the GPIO property name suffix to "-gpios";
> - switched to usign extcon_set_cable_state_() API;
> - switched to using the gpiod/sleeping 'gpiolib' APIs;
> - addded error messages to max3355_probe();
> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
> - renamed 'ret' variable to 'err' in max3355_probe();
> - expanded the Kconfig entry help text;
> - added vendor name to the patch summary, the bindings document, the Kconfig
> entry, the driver heading comment, the module description, and the change
> log;
> - fixed up and reformatted the change log.
>
> Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
> drivers/extcon/Kconfig |8
> drivers/extcon/Makefile |1
> drivers/extcon/extcon-max3355.c | 151
>
> 4 files changed, 181 insertions(+)
>
> Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> ===
> --- /dev/null
> +++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> @@ -0,0 +1,21 @@
> +Maxim Integrated MAX3355 USB OTG chip
> +-
> +
> +MAX3355 integrates a charge pump and comparators to enable a system with an
> +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> +device.
> +
> +Required properties:
> +- compatible: should be "maxim,max3355";
> +- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
> pin
> + connected to the MAX3355's SHDN# pin;
> +- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
> + connected to the MAX3355's ID_OUT pin.
> +
> +Example (Koelsch board):
You mean that "koelsch" board might be arch/arm/boot/dts/r8a7791-koelsch.dts.
But, the max3355 dt node isn't really included in r8a7791-koelsch.dts.
I recommend that you add the accurate information because the wrong
info causes the confusion. So, I'd like you to change it as following:
"Example (Koelsch board):" -> "Example:"
After adding the max3355 dt node to Koelsch board on separate patch,
you modify this documentation for real usage case of max3355 dt node.
> +
> + usb-otg {
> + compatible = "maxim,max3355";
> + maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
> + id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
> + };
> Index: extcon/drivers/extcon/Kconfig
> ===
> --- extcon.orig/drivers/extcon/Kconfig
> +++ extcon/drivers/extcon/Kconfig
> @@ -52,6 +52,14 @@ config EXTCON_MAX14577
> Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
> detector and switch.
[snip]
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 0/3] Input: goodix - add axis swapping and axis inversion support
On Sat, Nov 21, 2015 at 02:30:19PM +0100, Karsten Merker wrote: > Hello, > > this is v4 of my "Input: goodix - add axis swapping and axis inversion > support" patchset. > > The goodix touchscreen driver has gained device-tree support in kernel > 4.1, but doesn't currently support the touchscreen-swapped-x-y, > touchscreen-inverted-x and touchscreen-inverted-y properties. > On systems which combine a portrait-mode display with a landscape-mode > touchscreen, such as e.g. the MSI Primo 81 tablet, support for these > features is necessary to have the touchscreen and the display use the > same coordinate system. > > With support for axis inversion, the "rotated_screen" flag in the > driver can also be removed, as "rotated_screen" is just a special case > of x/y axis inversion. > > This patchset sits on top of the "[PATCH v11 0/8] Goodix touchscreen > enhancements" series by Irina Tirdea: > https://www.spinics.net/lists/linux-input/msg42146.html > > The axis swapping has successfully been tested on an MSI Primo 81 > tablet and on a Wexler TAB7200 tablet; the x/y inversion resp. > the rotated_screen functionality has successfully been tested on > a WinBook TW100. Folded 3 into 1 and applied everything, see my goodix branch. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 0/8] Goodix touchscreen enhancements
On Thu, Nov 19, 2015 at 02:26:33PM +0200, Irina Tirdea wrote: > This patchset depends on Dmitry's patch that fixes the > GPIO ACPI API[1], so devm_gpiod_get_optional can be properly > used in the code. > > [1] https://lkml.org/lkml/2015/11/11/465 Applied 1 through 5 (see my goodix branch), looking at the rest. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
On 2015년 12월 18일 06:20, Sergei Shtylyov wrote:
> Hello.
>
> On 12/17/2015 05:34 AM, Chanwoo Choi wrote:
>
>>> On 2015년 12월 17일 03:07, Sergei Shtylyov wrote:
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov
---
Changes in version 3:
- reformatted the change log.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save
power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the
Kconfig
entry, the driver heading comment, the module description, and the
change log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig |8
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 153
4 files changed, 183 insertions(+)
>>
>> [snip]
>>
+return 0;
+}
+
+static int max3355_remove(struct platform_device *pdev)
+{
+struct max3355_data *data = platform_get_drvdata(pdev);
+
+gpiod_set_value_cansleep(data->shdn_gpiod, 0);
>>
>> Don't need to handle the 'shdn' gpio on resume/suspend funtcion?
>>
>> But, if the interrput of id gpio is used for wakeup source,
>> there is no reason to handle it for suspend mode.
>
>You told me to pass IRQF_NO_SUSPEND to devm_request_threaded_irq(), didn't
> you?
Yes. You add the this flag on v4 patch. Looks good to me.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver
On 2015년 12월 18일 09:34, Chanwoo Choi wrote: > Hi, > > On 2015년 12월 15일 12:41, Krzysztof Kozlowski wrote: >> On 14.12.2015 15:38, Chanwoo Choi wrote: >>> This patch adds the generic exynos bus frequency driver for AMBA AXI bus >>> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC >>> have the common architecture for bus between DRAM and sub-blocks in SoC. >>> This driver can support the generic bus frequency driver for Exynos SoCs. >>> >>> In devicetree, Each bus block has a bus clock, regulator, operation-point >>> and devfreq-event devices which measure the utilization of each bus block. >>> >>> Signed-off-by: Chanwoo Choi >>> [linux.amoon: Tested on Odroid U3] >>> Tested-by: Anand Moon >>> --- >>> drivers/devfreq/Kconfig | 15 ++ >>> drivers/devfreq/Makefile| 1 + >>> drivers/devfreq/exynos/Makefile | 1 + >>> drivers/devfreq/exynos/exynos-bus.c | 449 >>> >>> 4 files changed, 466 insertions(+) >>> create mode 100644 drivers/devfreq/exynos/exynos-bus.c >>> >>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig >>> index 64281bb2f650..55ec774f794c 100644 >>> --- a/drivers/devfreq/Kconfig >>> +++ b/drivers/devfreq/Kconfig >>> @@ -66,6 +66,21 @@ config DEVFREQ_GOV_USERSPACE >>> >>> comment "DEVFREQ Drivers" >>> >>> +config ARM_EXYNOS_BUS_DEVFREQ >>> + bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver" >>> + depends on ARCH_EXYNOS >>> + select DEVFREQ_GOV_SIMPLE_ONDEMAND >>> + select DEVFREQ_EVENT_EXYNOS_PPMU >>> + select PM_DEVFREQ_EVENT >>> + select PM_OPP >>> + help >>> + This adds the common DEVFREQ driver for Exynos Memory bus. Exynos >>> + Memory bus has one more group of memory bus (e.g, MIF and INT block). >>> + Each memory bus group could contain many memoby bus block. It reads >>> + PPMU counters of memory controllers by using DEVFREQ-event device >>> + and adjusts the operating frequencies and voltages with OPP support. >>> + This does not yet operate with optimal voltages. >>> + >>> config ARM_EXYNOS4_BUS_DEVFREQ >>> bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver" >>> depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) && >>> !ARCH_MULTIPLATFORM >>> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile >>> index 5134f9ee983d..375ebbb4fcfb 100644 >>> --- a/drivers/devfreq/Makefile >>> +++ b/drivers/devfreq/Makefile >>> @@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o >>> obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o >>> >>> # DEVFREQ Drivers >>> +obj-$(CONFIG_ARCH_EXYNOS) += exynos/ >> >> Why limiting it to ARCH_EXYNOS? Are there real dependencies on exynos >> mach code? Or on ARM code? > > There is no dependency. > >> >> If not, then this probably should be obj-y to allow compile testing. >> Particular objects would be selected by ARM_EXYNOS_BUS_DEVFREQ. > > OK. I'll alter it as obj-y. As you commented, CONFIG_ARM_EXYNOS_BUS_DEVFREQ is more appropriate without exynos/ directory as following: +obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
On Thu, Dec 17, 2015 at 04:29:01PM -0800, Brian Norris wrote:
> On Tue, Dec 08, 2015 at 06:21:00AM +, Bean Huo 霍斌斌 wrote:
> OK, so I think your patch is broken:
>
> > > commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
> > > SPI NOR")
>
> How did you test this? Specifically, this can't possibly have worked
> with a regular drivers/spi/ controllers, since:
>
> (a) you're enabling 4/4/4 (i.e., "Quad mode") on the flash but
> (b) m25p80_read() only sets .rx_bits for the data; i.e., it's using
> 1/1/4 (i.e., "Extended mode")
>
> I'm tempted to essentially revert that, as it looks essentially
> untested. It would be nice to have a cleaner baseline before trying to
> extend it with Cyrille's work.
>
> Cyrille, what do you think? Is my analysis at all correct here? (Sorry
> if this is addressed elsewhere; there's a lot of text in this
> conversation, but I'm getting hung up very early.) And if so, does it
> hurt to just drop Micron "Quad mode" (4/4/4)?
It looks like you address some of this in patch 2, where you (as I do)
claim that Micron support is broken. It seems to me that it could be
better to kill it than to try to fix it. But maybe that's just the
frustrated maintainer in me speaking.
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 0/19] Add Analogix Core Display Port Driver
Hi Heiko,
On 12/18/2015 07:51 AM, Heiko Stübner wrote:
Hi Yakir,
Am Mittwoch, 16. Dezember 2015, 11:20:18 schrieb Yakir Yang:
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM
I'm really sorry for not thinking of this earlier, but I think we'll be doing
the atomic modesetting conversion of the drm/kms driver first - see v3 series
from Mark Yao.
Could you handle necessary changes to make it apply and work _after_ the
atomic modesetting conversion please?
Sure, I also want to rebase on Mark's atomic series. Would send the new
[PATCH v11.1 01/19] out today :)
- Yakir
Thanks
Heiko
But there are still three light registers setting differents bewteen
exynos and rk3288.
1. RK3288 have five special pll resigters which not indicata in exynos
dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
register).
This series have been well tested on Rockchip platform with eDP panel on
Jerry Chromebook and Display Port Monitor on RK3288 board. Also I have
tested on Samsung Snow and Peach Pit Chromebooks, and thanks to
Javier@Samsung help to retest the whole series on Samsung Exynos5800 Peach
Pi Chromebook, glad to say that things works rightlly.
Thanks,
- Yakir
Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
the panel unprepare from bridge->disable to unbind time. (Heiko)
Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here
(Heiko) - Add the ack from Rob Herring
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
BIT(4) -> BIT(20)
- Remove the surplus "plat_data" check. (Heiko)
- switch (dp->plat_data && dp->plat_data->dev_type) {
+ switch (dp->plat_data->dev_type) {
Changes in v9:
- Document more details for 'ports' property.
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
- Remove the specific address in the example node name. (Heiko)
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
to avoid -EOVERFLOW error (Krzysztof)
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)
- Simplify the commit message. (Kishon)
Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
- hpd-gpio = <&gpx2 6 0>;
+ hpd-gpios = <&gpx2 6 0>;
Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
attch function. Cause once platform failed at attach, core driver should
still failed, so no need to init connector before platform attached
(Krzysztof) - Keep code style no changes with the previous exynos_dp_code.c
in this patch, and update commit message about the new export symbol
(Krzysztof) - Gather the device type patch (v4 11/16) into this one.
(Krzysztof) - leave out the connector registration to analogix platform
driver. (Thierry) - Resequence this patch after analogix_dp driver have
been split
from exynos_dp code, and rephrase reasonable commit message, and
remove some controversial style (Krzysztof)
- analogix_dp_write_byte_to_dpcd(
- dp, DP_TEST_RESPONSE,
+ analogix_dp_write_byte_to_dpcd(dp,
+ DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use
"of_property_read_u32" to get the backword timing values. Krzysztof suggest
me that driver could use the "of_property_read_bool" to get backword timing
values, but that interfacs wo
Re: [PATCH v4 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver
Hi, On 2015년 12월 15일 12:41, Krzysztof Kozlowski wrote: > On 14.12.2015 15:38, Chanwoo Choi wrote: >> This patch adds the generic exynos bus frequency driver for AMBA AXI bus >> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC >> have the common architecture for bus between DRAM and sub-blocks in SoC. >> This driver can support the generic bus frequency driver for Exynos SoCs. >> >> In devicetree, Each bus block has a bus clock, regulator, operation-point >> and devfreq-event devices which measure the utilization of each bus block. >> >> Signed-off-by: Chanwoo Choi >> [linux.amoon: Tested on Odroid U3] >> Tested-by: Anand Moon >> --- >> drivers/devfreq/Kconfig | 15 ++ >> drivers/devfreq/Makefile| 1 + >> drivers/devfreq/exynos/Makefile | 1 + >> drivers/devfreq/exynos/exynos-bus.c | 449 >> >> 4 files changed, 466 insertions(+) >> create mode 100644 drivers/devfreq/exynos/exynos-bus.c >> >> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig >> index 64281bb2f650..55ec774f794c 100644 >> --- a/drivers/devfreq/Kconfig >> +++ b/drivers/devfreq/Kconfig >> @@ -66,6 +66,21 @@ config DEVFREQ_GOV_USERSPACE >> >> comment "DEVFREQ Drivers" >> >> +config ARM_EXYNOS_BUS_DEVFREQ >> +bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver" >> +depends on ARCH_EXYNOS >> +select DEVFREQ_GOV_SIMPLE_ONDEMAND >> +select DEVFREQ_EVENT_EXYNOS_PPMU >> +select PM_DEVFREQ_EVENT >> +select PM_OPP >> +help >> + This adds the common DEVFREQ driver for Exynos Memory bus. Exynos >> + Memory bus has one more group of memory bus (e.g, MIF and INT block). >> + Each memory bus group could contain many memoby bus block. It reads >> + PPMU counters of memory controllers by using DEVFREQ-event device >> + and adjusts the operating frequencies and voltages with OPP support. >> + This does not yet operate with optimal voltages. >> + >> config ARM_EXYNOS4_BUS_DEVFREQ >> bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver" >> depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) && >> !ARCH_MULTIPLATFORM >> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile >> index 5134f9ee983d..375ebbb4fcfb 100644 >> --- a/drivers/devfreq/Makefile >> +++ b/drivers/devfreq/Makefile >> @@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o >> obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o >> >> # DEVFREQ Drivers >> +obj-$(CONFIG_ARCH_EXYNOS) += exynos/ > > Why limiting it to ARCH_EXYNOS? Are there real dependencies on exynos > mach code? Or on ARM code? There is no dependency. > > If not, then this probably should be obj-y to allow compile testing. > Particular objects would be selected by ARM_EXYNOS_BUS_DEVFREQ. OK. I'll alter it as obj-y. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next 0/5] mtd: spi-nor: add driver for Atmel QSPI controller
Hi Bean,
On Tue, Dec 08, 2015 at 06:21:00AM +, Bean Huo 霍斌斌 wrote:
> > -Original Message-
> > From: Brian Norris [mailto:computersforpe...@gmail.com]
> >
> > I'll admit I'm a little fuzzy on the differences between dual and quad
> > modes on
> > various flash manufacturers. Can you help clear it up for me?
>
> For Micron SPI NOR spi quad mode, means that Qaud I/O prototocol, it follows
> I/O
> Bus width is command-address-Data 4-4-4, at this time, DQ0,DQ1,DQ2,DQ3
> are all used to transfer address/command/data. For this maybe not the same
> between
> different flash manufactures. For example, for Spansion Qspi NOR, its all
> instructions are
> transferred from host to memory as a single bit serial sequence on the DQ0
> signal, even under
> Quad mode. Dual mode the same as Qaud mode scenario.
>
> for SPI NOR 1-1-4, means command and address are transferred on the DQ0,
> but for data, being transferred on DQ0,DQ1,DQ2,DQ3.For this, it is the same
> between different flash manufacturers. Of course, at this moment, SPI NOR
> should work under extended I/O mode.
OK, so to make these statements *much* shorter:
* Micron "Quad Mode" means putting the flash in a 4/4/4 mode
* Spansion (and all others?) are using 1/1/4 modes
Correct?
> > I think some of the comments on patch 2 help too, but I'll just comment here
> > for now.
> > It looks like the current driver has problems regarding the non 1-x-y modes
> > (e.g., 4-4-4), right? But I see that spi-nor.c never tries to send a 4_4_4
> > command; it only sets read_opcode to SPINOR_OP_READ_1_1_{1,2,4}. So is
> > this an oversight in patches like Bean's patch?
>
> For SPINOR_OP_READ_1_1_{1,2,4} commands, Spi NOR actually works under
> Extended I/O mode, not Quad mode. They just push Spi NOR output data by Quad
> mode,
> Command and address still following extended I/O mode.
The naming is confusing enough here... so in your words, "extended"
means 1/1/{1,2,4} (i.e., command, and maybe address, use 1 line, but
data goes on 4)? And "quad" means 4/4/4?
> For 4-4-4 I/O protocol, SPI NOR should change to Quad mode(just as my patch),
> of course, SPI controller should support this. for Micron Qspi NOR, under
> quad mode,
> all commands/address/data are transferred on DQ0,DQ1,DQ2,DQ3 signals. No
> matter what
> kind of command.
OK, so I think your patch is broken:
> > commit 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron
> > SPI NOR")
How did you test this? Specifically, this can't possibly have worked
with a regular drivers/spi/ controllers, since:
(a) you're enabling 4/4/4 (i.e., "Quad mode") on the flash but
(b) m25p80_read() only sets .rx_bits for the data; i.e., it's using
1/1/4 (i.e., "Extended mode")
I'm tempted to essentially revert that, as it looks essentially
untested. It would be nice to have a cleaner baseline before trying to
extend it with Cyrille's work.
Cyrille, what do you think? Is my analysis at all correct here? (Sorry
if this is addressed elsewhere; there's a lot of text in this
conversation, but I'm getting hung up very early.) And if so, does it
hurt to just drop Micron "Quad mode" (4/4/4)?
(AIUI, this won't exactly be a panacea, since you mention bootloaders
that start us off in quad mode, so we can't use single I/O 0x9f READ
ID.)
> > Why would we even need to enable quad modes like that, if we're not going
> > to send the 4-4-4 opcodes?
> I think, in order to high speed SPI NOR, after enable quad mode,
> SPINOR_OP_READ_1_1_{1,2,4} commands don't need any more, normal read command
> (0x03)
> Can implement as them.
OK. That's odd, but I guess it doesn't matter much. It just makes it a
little less obvious what's going on.
> > My next question (if my understanding is roughly correct) is, do we need the
> > 4-4-4 modes, and what risks come with them? I understand we can shorten
> > the command and address phases, but does that alone yield much
> > performance benefit? And I think the risk is that a given system might not
> > be
> > prepared for the flash to be in a 4-4-4 mode, if the boot code tries to use
> > 1-x-y
> > commands.
>
> As far as my current experience and knowledge, this still need to be enabled,
> especially for
> fast boot, and some IOT devices to store info into SPI NOR.
Do you have any data to about the speed? And you haven't addressed the
risks. There are definitely risks. Cyrille looks like he's trying to
address the risks (e.g., use volatile modes whenever possible), but it
doesn't seem that you are.
> For this patches, my current concern is that host side how to get different
> I/O protocol changes,
> and distinguish between different flash manufacturers I/O mode.
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8 v6] thermal: rcar: enable to use thermal-zone on DT
From: Kuninori Morimoto
This patch enables to use thermal-zone on DT if it was calles as
"renesas,rcar-thermal-gen2".
Previous style (= non thermal-zone) is still supported by
"renesas,rcar-thermal" to keep compatibility for "git bisect".
Signed-off-by: Kuninori Morimoto
---
v5 -> v6
- "was call" -> "was called"
- add reason why it keeps previous style
.../devicetree/bindings/thermal/rcar-thermal.txt | 37 +-
drivers/thermal/rcar_thermal.c | 45 +++---
2 files changed, 75 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
index 332e625..e5ee3f1 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
@@ -1,8 +1,9 @@
* Renesas R-Car Thermal
Required properties:
-- compatible : "renesas,thermal-", "renesas,rcar-thermal"
- as fallback.
+- compatible : "renesas,thermal-",
+ "renesas,rcar-gen2-thermal" (with thermal-zone) or
+ "renesas,rcar-thermal" (without thermal-zone) as
fallback.
Examples with soctypes are:
- "renesas,thermal-r8a73a4" (R-Mobile APE6)
- "renesas,thermal-r8a7779" (R-Car H1)
@@ -36,3 +37,35 @@ thermal@e61f {
0xe61f0300 0x38>;
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
};
+
+Example (with thermal-zone):
+
+thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+
+ thermal-sensors = <&thermal>;
+
+ trips {
+ cpu-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type= "critical";
+ };
+ };
+ cooling-maps {
+ };
+ };
+};
+
+thermal: thermal@e61f {
+ compatible ="renesas,thermal-r8a7790",
+ "renesas,rcar-gen2-thermal",
+ "renesas,rcar-thermal";
+ reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
+ interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp5_clks R8A7790_CLK_THERMAL>;
+ power-domains = <&cpg_clocks>;
+ #thermal-sensor-cells = <0>;
+};
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 30602f2..e92f29b 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -75,8 +76,10 @@ struct rcar_thermal_priv {
#define rcar_has_irq_support(priv) ((priv)->common->base)
#define rcar_id_to_shift(priv) ((priv)->id * 8)
+#define USE_OF_THERMAL 1
static const struct of_device_id rcar_thermal_dt_ids[] = {
{ .compatible = "renesas,rcar-thermal", },
+ { .compatible = "renesas,rcar-gen2-thermal", .data = (void
*)USE_OF_THERMAL },
{},
};
MODULE_DEVICE_TABLE(of, rcar_thermal_dt_ids);
@@ -200,9 +203,9 @@ err_out_unlock:
return ret;
}
-static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
+static int rcar_thermal_get_current_temp(struct rcar_thermal_priv *priv,
+int *temp)
{
- struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
int tmp;
int ret;
@@ -226,6 +229,20 @@ static int rcar_thermal_get_temp(struct
thermal_zone_device *zone, int *temp)
return 0;
}
+static int rcar_thermal_of_get_temp(void *data, int *temp)
+{
+ struct rcar_thermal_priv *priv = data;
+
+ return rcar_thermal_get_current_temp(priv, temp);
+}
+
+static int rcar_thermal_get_temp(struct thermal_zone_device *zone, int *temp)
+{
+ struct rcar_thermal_priv *priv = rcar_zone_to_priv(zone);
+
+ return rcar_thermal_get_current_temp(priv, temp);
+}
+
static int rcar_thermal_get_trip_type(struct thermal_zone_device *zone,
int trip, enum thermal_trip_type *type)
{
@@ -282,6 +299,10 @@ static int rcar_thermal_notify(struct thermal_zone_device
*zone,
return 0;
}
+static const struct thermal_zone_of_device_ops rcar_thermal_zone_of_ops = {
+ .get_temp = rcar_thermal_of_get_temp,
+};
+
static struct thermal_zone_device_ops rcar_thermal_zone_ops = {
.get_temp = rcar_thermal_get_temp,
.get_trip_type = rcar_thermal_get_trip_type,
@@ -318,14 +339,20 @@ static void rcar_thermal_work(struct work_struct *work)
priv = container_of(work, struct rcar_thermal_priv, work.work);
- rcar_thermal_get_temp(priv->zone, &cctemp);
+ ret = rcar_thermal_get_curren
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
On 17.12.2015 23:36, Sergei Shtylyov wrote:
> Hello.
>
> On 12/17/2015 3:53 AM, Krzysztof Kozlowski wrote:
>
>>> Maxim Integrated MAX3355E chip integrates a charge pump and
>>> comparators to
>>> enable a system with an integrated USB OTG dual-role transceiver to
>>> function as an USB OTG dual-role device. In addition to
>>> sensing/controlling
>>> Vbus, the chip also passes thru the ID signal from the USB OTG
>>> connector.
>>> On some Renesas boards, this signal is just fed into the SoC thru a GPIO
>>> pin -- there's no real OTG controller, only host and gadget USB
>>> controllers
>>> sharing the same USB bus; however, we'd like to allow host or gadget
>>> drivers to be loaded depending on the cable type, hence the need for the
>>> MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
>>> (however, we aren't currently interested in them), the OFFVBUS#
>>> signal is
>>> controlled by the host controllers, there's also the SHDN# signal
>>> wired to
>>> a GPIO, it should be driven high for the normal operation.
>>>
>>> Signed-off-by: Sergei Shtylyov
>>>
>>> ---
>>> Changes in version 3:
>>> - reformatted the change log.
>>>
>>> Changes in version 2:
>>> - added the USB gadget cable support;
>>> - added the remove() driver method which drives SHDN# GPIO low to
>>> save power;
>>> - dropped vendor prefix from the ID GPIO property name;
>>> - changed the GPIO property name suffix to "-gpios";
>>> - switched to usign extcon_set_cable_state_() API;
>>> - switched to using the gpiod/sleeping 'gpiolib' APIs;
>>> - addded error messages to max3355_probe();
>>> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
>>> - renamed 'ret' variable to 'err' in max3355_probe();
>>> - expanded the Kconfig entry help text;
>>> - added vendor name to the patch summary, the bindings document, the
>>> Kconfig
>>>entry, the driver heading comment, the module description, and the
>>> change log;
>>> - fixed up and reformatted the change log.
>>>
>>> Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
>>> drivers/extcon/Kconfig |8
>>> drivers/extcon/Makefile |1
>>> drivers/extcon/extcon-max3355.c | 153
>>>
>>> 4 files changed, 183 insertions(+)
>>>
>>> Index:
>>> renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
>>> ===
>>> --- /dev/null
>>> +++ renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
>>> @@ -0,0 +1,21 @@
>>> +Maxim Integrated MAX3355 USB OTG chip
>>> +-
>>> +
>>> +MAX3355 integrates a charge pump and comparators to enable a system
>>> with an
>>> +integrated USB OTG dual-role transceiver to function as a USB OTG
>>> dual-role
>>> +device.
>>> +
>>> +Required properties:
>>> +- compatible: should be "maxim,max3355";
>>> +- maxim,shdn-gpios: should contain a phandle and GPIO specifier for
>>> the GPIO pin
>>> + connected to the MAX3355's SHDN# pin;
>>
>> Could you add some indentation to the wrapped line for this property?
>> For readability.
>
>If it's not indented enough, I can add more spaces/tabs.
Ahh, now I see it is sufficient. I need fix my email client.
>
>>> +- id-gpios: should contain a phandle and GPIO specifier for the GPIO
>>> pin
>>> + connected to the MAX3355's ID_OUT pin.
>>
>> Ditto.
>>
>> Why this property lacks the vendor prefix i(n comparison to shdn-gpios
>> which has the prefix)?
>
>Since the extcon-usb-gpio driver uses "id-gpio" prop already. I can
> add back the vendor prefix if you insist.
It is for USB ID and palmas has it already as well so I do not insist.
Seems generic.
>
> [...]
>>> Index: renesas/drivers/extcon/extcon-max3355.c
>>> ===
>>> --- /dev/null
>>> +++ renesas/drivers/extcon/extcon-max3355.c
>>> @@ -0,0 +1,153 @@
> [...]
>>> +static int max3355_probe(struct platform_device *pdev)
>>> +{
>>> + struct device_node *np = pdev->dev.of_node;
>>> + struct max3355_data *data;
>>> + struct gpio_desc *gpiod;
>>> + int irq, err;
>>> +
>>> + data = devm_kzalloc(&pdev->dev, sizeof(struct max3355_data),
>>> + GFP_KERNEL);
>>> + if (!data)
>>> + return -ENOMEM;
>>> +
>>> + data->edev = devm_extcon_dev_allocate(&pdev->dev,
>>> max3355_cable);
>>> + if (IS_ERR(data->edev)) {
>>> + dev_err(&pdev->dev, "failed to allocate extcon
>>> device\n");
>>> + return PTR_ERR(data->edev);
>>> + }
>>> + data->edev->name = kstrdup(np->name, GFP_KERNEL);
>>
>> I think it is not needed any more (extcon_dev_register()) will set it.
>> Anyway there is no checking for NULL return value and no freeing in
>> error/exit paths.
>
>Oops, will fix.
>
> [...]
>>> +static struct platform_driv
Re: [PATCH v11 0/19] Add Analogix Core Display Port Driver
Hi Yakir,
Am Mittwoch, 16. Dezember 2015, 11:20:18 schrieb Yakir Yang:
>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM
I'm really sorry for not thinking of this earlier, but I think we'll be doing
the atomic modesetting conversion of the drm/kms driver first - see v3 series
from Mark Yao.
Could you handle necessary changes to make it apply and work _after_ the
atomic modesetting conversion please?
Thanks
Heiko
> But there are still three light registers setting differents bewteen
> exynos and rk3288.
> 1. RK3288 have five special pll resigters which not indicata in exynos
>dp controller.
> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>between rk3288 and exynos.
> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
>register).
>
> This series have been well tested on Rockchip platform with eDP panel on
> Jerry Chromebook and Display Port Monitor on RK3288 board. Also I have
> tested on Samsung Snow and Peach Pit Chromebooks, and thanks to
> Javier@Samsung help to retest the whole series on Samsung Exynos5800 Peach
> Pi Chromebook, glad to say that things works rightlly.
>
> Thanks,
> - Yakir
>
>
> Changes in v11:
> - Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
> - Correct the title of this rockchip dp phy document(Rob)
> - Add the ack from Rob Herring
> - Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
> - Add the ack from Rob Herring
> - Revert parts of Gustavo Padovan's changes in commit:
> drm/exynos: do not start enabling DP at bind() phase
> Add dp phy poweron function in bind time.
> - Move the panel prepare from get_modes time to bind time, and move
> the panel unprepare from bridge->disable to unbind time. (Heiko)
>
> Changes in v10:
> - Add the ack from Rob Herring
> - Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here
> (Heiko) - Add the ack from Rob Herring
> - Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
> BIT(4) -> BIT(20)
> - Remove the surplus "plat_data" check. (Heiko)
> - switch (dp->plat_data && dp->plat_data->dev_type) {
> + switch (dp->plat_data->dev_type) {
>
> Changes in v9:
> - Document more details for 'ports' property.
> - Removed the unused the variable "res" in probe function. (Heiko)
> - Removed the unused head file.
>
> Changes in v8:
> - Correct the right document path of display-timing.txt (Heiko)
> - Correct the misspell of 'from' to 'frm'. (Heiko)
> - Modify the commit subject name. (Heiko)
> - Fix the mixed spacers on macro definitions. (Heiko)
> - Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
> - Remove the specific address in the example node name. (Heiko)
>
> Changes in v7:
> - Back to use the of_property_read_bool() interfacs to provoid backward
> compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
> to avoid -EOVERFLOW error (Krzysztof)
> - Simply the commit message. (Kishon)
> - Symmetrical enable/disbale the phy clock and power. (Kishon)
> - Simplify the commit message. (Kishon)
>
> Changes in v6:
> - Fix the Kconfig recursive dependency (Javier)
> - Fix Peach Pit hpd property name error:
> - hpd-gpio = <&gpx2 6 0>;
> + hpd-gpios = <&gpx2 6 0>;
>
> Changes in v5:
> - Correct the check condition of gpio_is_valid when driver try to get
> the "hpd-gpios" DT propery. (Heiko)
> - Move the platform attach callback in the front of core driver bridge
> attch function. Cause once platform failed at attach, core driver should
> still failed, so no need to init connector before platform attached
> (Krzysztof) - Keep code style no changes with the previous exynos_dp_code.c
> in this patch, and update commit message about the new export symbol
> (Krzysztof) - Gather the device type patch (v4 11/16) into this one.
> (Krzysztof) - leave out the connector registration to analogix platform
> driver. (Thierry) - Resequence this patch after analogix_dp driver have
> been split
> from exynos_dp code, and rephrase reasonable commit message, and
> remove some controversial style (Krzysztof)
> - analogix_dp_write_byte_to_dpcd(
> - dp, DP_TEST_RESPONSE,
> + analogix_dp_write_byte_to_dpcd(dp,
> + DP_TEST_RESPONSE,
> DP_TEST_EDID_CHECKSUM_WRITE);
> - Switch video timing type to "u32", so driver could use
> "of_property_read_u32" to get the backword timing values. Krzysztof suggest
> me that driver could use the "of_property_read_bool" to get backword timing
> values, but that interfacs wo
Re: [PATCH v1 0/6] Support the rk3036 Kylin board
Hi Caesar, Kees, Am Donnerstag, 17. Dezember 2015, 11:45:06 schrieb Kees Cook: > On Thu, Dec 17, 2015 at 6:21 AM, Caesar Wang wrote: > > Kylin-board is based on RK3036 SOCs, add the initiation > > version for working. > > > > This series patches have the following decriptions: > > > > PATCH[1/6]: > > ARM: dts: fix the correct pinctrl control for rk3036 > > > > The pinctrl gpio pull up/down is incorrect since the rk3036 SoCs > > can't set the status in the internal. > > --- > > > > PATCH[2/6]: > > ARM: dts: add the lcdc and hdmi node for rk3036 > > > > Add the devices is related to display. > > Based on the series patches of Mark Yao's > > --- > > > > PATCH[3/6]: > > ARM: dts: add the sdio/sdmmc node for rk3036 > > > > Add the wifi/sd card work for kylin board. > > --- > > > > PATCH[4/6]: > > ARM: dts: rockchip: add the kylin board for rk3036 > > > > Add the dts for kylin board. > > --- > > > > PATCH[5/6]: > > ARM: dts: add the sound codec for kylin board > > > > Make the codec rt5616 working on kylin board. > > The realteak have been upstream for Mark Brown, > > I guess need some days to review. > > > > --- > > > > PATCH[6/6]: > > ARM: dts: add the sdio node for kylin board > > > > Enable the sdio for kylin board. > > --- > > Thanks for sending this! > > Reviewed-by: Kees Cook > > Some thoughts: maybe collapse 4, 5, and 6 together, since it's a new file? @Caesar, no need to resend, I can do that merging myself. After we clarified the authorship of patch1 ;-) . Except the audio patch, as we're missing the realtek codec driver. I'll also drop the lcdc+hdmi parts for now, as the relevant parts aren't in any maintainer-tree yet. The ordering is for this: - atomic conversion - rk3036 vop - inno-hdmi driver - dts changes last The driver for the Innosilicon hdmi driver is from November, had one comment from me and Caesar+ Yakir should make sure it works with the atomic modesetting variant of the drm/kms driver please. (And probably resend the series fixing that one tiny comment). Heiko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 5/6] ARM: dts: add the sound codec for kylin board
Am Donnerstag, 17. Dezember 2015, 22:21:51 schrieb Caesar Wang:
> Support the rt5616 codec for kylin board, but we need
> enable the i2s firstly.
>
> Signed-off-by: Caesar Wang
> ---
>
> arch/arm/boot/dts/rk3036-kylin.dts | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3036-kylin.dts
> b/arch/arm/boot/dts/rk3036-kylin.dts index 69b1e1e..296139b 100644
> --- a/arch/arm/boot/dts/rk3036-kylin.dts
> +++ b/arch/arm/boot/dts/rk3036-kylin.dts
> @@ -46,6 +46,28 @@
> model = "Rockchip RK3036 KylinBoard";
> compatible = "rockchip,rk3036-kylin", "rockchip,rk3036";
>
> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,name = "rockchip,rt5616-codec";
> + simple-audio-card,mclk-fs = <64>;
> + simple-audio-card,widgets =
> + "Microphone", "Microphone Jack",
> + "Headphone", "Headphone Jack";
> + simple-audio-card,routing =
> + "MIC1", "Microphone Jack",
> + "MIC2", "Microphone Jack",
> + "Microphone Jack", "micbias1",
> + "Headphone Jack", "HPOL",
> + "Headphone Jack", "HPOR";
> + simple-audio-card,cpu {
> + sound-dai = <&i2s>;
> + };
> + simple-audio-card,codec {
> + sound-dai = <&rt5616>;
> + };
> + };
> +
> vcc_sys: vsys-regulator {
> compatible = "regulator-fixed";
> regulator-name = "vcc_sys";
> @@ -261,6 +283,17 @@
>
> &i2c2 {
> status = "okay";
> +
> + rt5616: rt5616@1b {
> + #sound-dai-cells = <0>;
> + compatible = "rt5616";
> + reg = <0x1b>;
> + };
I don't see that codec in the asoc-tree [0]. And the compatible
would of course also need to be "realtek,rt5616".
[0]
https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/tree/sound/soc/codecs?h=for-next
> +};
> +
> +&i2s {
> + #sound-dai-cells = <0>;
> + status = "okay";
> };
>
> &lcdc {
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 6/8] input: touchscreen: imx25 tcq driver
On Mon, Dec 14, 2015 at 02:53:52PM +0100, Markus Pargmann wrote:
> This is a driver for the imx25 ADC/TSC module. It controls the
> touchscreen conversion queue and creates a touchscreen input device.
> The driver currently only supports 4 wire touchscreens. The driver uses
> a simple conversion queue of precharge, touch detection, X measurement,
> Y measurement, precharge and another touch detection.
>
> This driver uses the regmap from the parent to setup some touch specific
> settings in the core driver and setup a idle configuration with touch
> detection.
>
> Signed-off-by: Markus Pargmann
> Signed-off-by: Denis Carikli
>
> [fix clock's period calculation]
> [fix calculation of the 'settling' value]
> Signed-off-by: Juergen Borleis
Acked-by: Dmitry Torokhov
Please merge with the rest of this MFD device.
> ---
>
> Notes:
> Changes in v10:
> - Renamed devicetree properties
>
> Changes in v9:
> - Added module description to Kconfig item
> - Fixed devm_ioremap_resource() return value check to use IS_ERR()
> - Removed return value of mx25_tcq_create_event_for_4wire()
> - Renamed most 'ret' variables through 'error'
> - Removed IRQF_ONESHOT
> - Rearranged threaded handler to not mix up samples from multiple
> measurements
>
> Changes in v7:
> - Moved clk_prepare_enable() and mx25_tcq_init() into mx25_tcq_open().
> This
>was done to be able to use devm_request_threaded_irq().
> - Cleanup of the probe function through above change
> - Removed mx25_tcq_remove(), not necessary now
>
> drivers/input/touchscreen/Kconfig | 9 +
> drivers/input/touchscreen/Makefile| 1 +
> drivers/input/touchscreen/fsl-imx25-tcq.c | 596
> ++
> 3 files changed, 606 insertions(+)
> create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c
>
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index ae33da7ab51f..873bf3697e35 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -811,6 +811,15 @@ config TOUCHSCREEN_USB_COMPOSITE
> To compile this driver as a module, choose M here: the
> module will be called usbtouchscreen.
>
> +config TOUCHSCREEN_MX25
> + tristate "Freescale i.MX25 touchscreen input driver"
> + depends on MFD_MX25_TSADC
> + help
> + Enable support for touchscreen connected to your i.MX25.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called fsl-imx25-tcq.
> +
> config TOUCHSCREEN_MC13783
> tristate "Freescale MC13783 touchscreen input driver"
> depends on MFD_MC13XXX
> diff --git a/drivers/input/touchscreen/Makefile
> b/drivers/input/touchscreen/Makefile
> index cbaa6abb08da..77a2ac54101a 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -45,6 +45,7 @@ obj-$(CONFIG_TOUCHSCREEN_INTEL_MID) += intel-mid-touch.o
> obj-$(CONFIG_TOUCHSCREEN_IPROC) += bcm_iproc_tsc.o
> obj-$(CONFIG_TOUCHSCREEN_LPC32XX)+= lpc32xx_ts.o
> obj-$(CONFIG_TOUCHSCREEN_MAX11801) += max11801_ts.o
> +obj-$(CONFIG_TOUCHSCREEN_MX25) += fsl-imx25-tcq.o
> obj-$(CONFIG_TOUCHSCREEN_MC13783)+= mc13783_ts.o
> obj-$(CONFIG_TOUCHSCREEN_MCS5000)+= mcs5000_ts.o
> obj-$(CONFIG_TOUCHSCREEN_MIGOR) += migor_ts.o
> diff --git a/drivers/input/touchscreen/fsl-imx25-tcq.c
> b/drivers/input/touchscreen/fsl-imx25-tcq.c
> new file mode 100644
> index ..fe9877a6af9e
> --- /dev/null
> +++ b/drivers/input/touchscreen/fsl-imx25-tcq.c
> @@ -0,0 +1,596 @@
> +/*
> + * Copyright (C) 2014-2015 Pengutronix, Markus Pargmann
> + *
> + * This program is free software; you can redistribute it and/or modify it
> under
> + * the terms of the GNU General Public License version 2 as published by the
> + * Free Software Foundation.
> + *
> + * Based on driver from 2011:
> + * Juergen Beisert, Pengutronix
> + *
> + * This is the driver for the imx25 TCQ (Touchscreen Conversion Queue)
> + * connected to the imx25 ADC.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static const char mx25_tcq_name[] = "mx25-tcq";
> +
> +enum mx25_tcq_mode {
> + MX25_TS_4WIRE,
> +};
> +
> +struct mx25_tcq_priv {
> + struct regmap *regs;
> + struct regmap *core_regs;
> + struct input_dev *idev;
> + enum mx25_tcq_mode mode;
> + unsigned int pen_threshold;
> + unsigned int sample_count;
> + unsigned int expected_samples;
> + unsigned int pen_debounce;
> + unsigned int settling_time;
> + struct clk *clk;
> + int irq;
> + struct device *dev;
> +};
> +
> +static struct regmap_config mx25_tcq_regconfig = {
> + .fast_io = true,
> + .max_register = 0x5c,
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
>
Re: [PATCH v1 1/6] ARM: dts: fix the correct pinctrl control for rk3036
Am Donnerstag, 17. Dezember 2015, 22:21:47 schrieb Caesar Wang:
> The pinctrl gpio pull up/down is incorrect since the rk3036 SoCs
> can't set the status in the internal.
>
> We should keep the default status for enable the gpio status,
> In fact, the pull_none is the disable the gpio pull up/down.
>
> Signed-off-by: Xing Zheng
> Signed-off-by: Caesar Wang
>From the signed-off-by's I guess this change was created by Xing (author),
right?
Heiko
> ---
>
> arch/arm/boot/dts/rk3036.dtsi | 34 +++---
> 1 file changed, 15 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
> index f8758bf..620e6e0 100644
> --- a/arch/arm/boot/dts/rk3036.dtsi
> +++ b/arch/arm/boot/dts/rk3036.dtsi
> @@ -427,12 +427,8 @@
> #interrupt-cells = <2>;
> };
>
> - pcfg_pull_up: pcfg-pull-up {
> - bias-pull-up;
> - };
> -
> - pcfg_pull_down: pcfg-pull-down {
> - bias-pull-down;
> + pcfg_pull_default: pcfg_pull_default {
> + bias-pull-pin-default;
> };
>
> pcfg_pull_none: pcfg-pull-none {
> @@ -473,18 +469,18 @@
> };
>
> emmc_cmd: emmc-cmd {
> - rockchip,pins = <2 1 RK_FUNC_2 &pcfg_pull_none>;
> + rockchip,pins = <2 1 RK_FUNC_2
> &pcfg_pull_default>;
> };
>
> emmc_bus8: emmc-bus8 {
> - rockchip,pins = <1 24 RK_FUNC_2
> &pcfg_pull_none>,
> - <1 25 RK_FUNC_2
> &pcfg_pull_none>,
> - <1 26 RK_FUNC_2
> &pcfg_pull_none>,
> - <1 27 RK_FUNC_2
> &pcfg_pull_none>,
> - <1 28 RK_FUNC_2
> &pcfg_pull_none>,
> - <1 29 RK_FUNC_2
> &pcfg_pull_none>,
> - <1 30 RK_FUNC_2
> &pcfg_pull_none>,
> - <1 31 RK_FUNC_2
> &pcfg_pull_none>;
> + rockchip,pins = <1 24 RK_FUNC_2
> &pcfg_pull_default>,
> + <1 25 RK_FUNC_2
> &pcfg_pull_default>,
> + <1 26 RK_FUNC_2
> &pcfg_pull_default>,
> + <1 27 RK_FUNC_2
> &pcfg_pull_default>,
> + <1 28 RK_FUNC_2
> &pcfg_pull_default>,
> + <1 29 RK_FUNC_2
> &pcfg_pull_default>,
> + <1 30 RK_FUNC_2
> &pcfg_pull_default>,
> + <1 31 RK_FUNC_2
> &pcfg_pull_default>;
> };
> };
>
> @@ -522,12 +518,12 @@
>
> uart0 {
> uart0_xfer: uart0-xfer {
> - rockchip,pins = <0 16 RK_FUNC_1 &pcfg_pull_up>,
> + rockchip,pins = <0 16 RK_FUNC_1
> &pcfg_pull_default>,
> <0 17 RK_FUNC_1
> &pcfg_pull_none>;
> };
>
> uart0_cts: uart0-cts {
> - rockchip,pins = <0 18 RK_FUNC_1 &pcfg_pull_up>;
> + rockchip,pins = <0 18 RK_FUNC_1
> &pcfg_pull_default>;
> };
>
> uart0_rts: uart0-rts {
> @@ -537,7 +533,7 @@
>
> uart1 {
> uart1_xfer: uart1-xfer {
> - rockchip,pins = <2 22 RK_FUNC_1
> &pcfg_pull_none>,
> + rockchip,pins = <2 22 RK_FUNC_1
> &pcfg_pull_default>,
> <2 23 RK_FUNC_1
> &pcfg_pull_none>;
> };
> /* no rts / cts for uart1 */
> @@ -545,7 +541,7 @@
>
> uart2 {
> uart2_xfer: uart2-xfer {
> - rockchip,pins = <1 18 RK_FUNC_2
> &pcfg_pull_none>,
> + rockchip,pins = <1 18 RK_FUNC_2
> &pcfg_pull_default>,
> <1 19 RK_FUNC_2
> &pcfg_pull_none>;
> };
> /* no rts / cts for uart2 */
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: lpc4337-ciaa: enable SCT-PWM
On 16 December 2015 at 13:55, Ariel D'Alessandro
wrote:
> Joachim,
>
> El 14/12/15 a las 19:48, Joachim Eastwood escribió:
>> Hi Ariel,
>>
>> Sorry for the late reply. I have just started to put together my DT
>> for 4.5 branch now.
>>
>> On 25 November 2015 at 13:28, Ariel D'Alessandro
>> wrote:
>>> (+To: Joachim)
>>>
>>> El 23/11/15 a las 09:37, Ariel D'Alessandro escribió:
Enable the PWM based on the State Configurable Timer (SCT) included in
the LPC4337 SoC of the CIAA-NXP board.
Signed-off-by: Ariel D'Alessandro
---
arch/arm/boot/dts/lpc4337-ciaa.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/lpc4337-ciaa.dts
b/arch/arm/boot/dts/lpc4337-ciaa.dts
index 03bdf77..1a23589 100644
--- a/arch/arm/boot/dts/lpc4337-ciaa.dts
+++ b/arch/arm/boot/dts/lpc4337-ciaa.dts
@@ -170,6 +170,10 @@
pinctrl-0 = <&enet_rmii_pins>;
};
+&sct_pwm {
+ status = "okay";
+};
+
>>
>> Isn't this a bit useless without any pinmux setup?
>
> Yes, it might be kind of useless. Do you think it shouldn't be enabled then?
It would be nice to have a board with sct-pwm enabled. Would it
possible for you to assign a pin to it?
regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] extcon: add Maxim MAX3355 driver
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
Changes in version 4:
- stopped calling kstrdup() for the device name;
- removed unneeded 'owner' field initializer;
- moved devm_extcon_allocate() call further down in the probe() method;
- extended the driver copyright;
- indented the continuation lines in the binding document.
Changes in version 3:
- reformatted the change log.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
entry, the driver heading comment, the module description, and the change log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig |8
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 151
4 files changed, 181 insertions(+)
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+Maxim Integrated MAX3355 USB OTG chip
+-
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
pin
+ connected to the MAX3355's SHDN# pin;
+- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+ usb-otg {
+ compatible = "maxim,max3355";
+ maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
+ id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
+ };
Index: extcon/drivers/extcon/Kconfig
===
--- extcon.orig/drivers/extcon/Kconfig
+++ extcon/drivers/extcon/Kconfig
@@ -52,6 +52,14 @@ config EXTCON_MAX14577
Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
detector and switch.
+config EXTCON_MAX3355
+ tristate "Maxim MAX3355 USB OTG EXTCON Support"
+ help
+ If you say yes here you get support for the USB OTG role detection by
+ MAX3355. The MAX3355 chip integrates a charge pump and comparators to
+ enable a system with an integrated USB OTG dual-role transceiver to
+ function as an USB OTG dual-role device.
+
config EXTCON_MAX77693
tristate "Maxim MAX77693 EXTCON Support"
depends on MFD_MAX77693 && INPUT
Index: extcon/drivers/extcon/Makefile
===
--- extcon.orig/drivers/extcon/Makefile
+++ extcon/drivers/extcon/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-a
obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o
+obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX77843) += extcon-max77843.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
Index: extcon/drivers/extcon/extcon-max3355.c
===
--- /dev
Re: [PATCH v4 0/4] Raspberry Pi power domains
Eric Anholt writes: > Update from v3 to move the driver under drivers/soc. I've placed it > under drivers/soc/bcm since that's how the other drivers under > drivers/soc are structured. Thanks, I like it better under drivers/soc too. Reviewed-by: Kevin Hilman Kevin > Alexander Aring (3): > ARM: bcm2835: add rpi power domain driver > dt-bindings: add rpi power domain driver bindings > ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. > > Eric Anholt (1): > ARM: bcm2835: Define two new packets from the latest firmware. > > .../bindings/soc/bcm/raspberrypi,bcm2835-power.txt | 47 > arch/arm/boot/dts/bcm2835-rpi.dtsi | 11 + > arch/arm/boot/dts/bcm2835.dtsi | 2 +- > drivers/soc/Kconfig| 1 + > drivers/soc/Makefile | 1 + > drivers/soc/bcm/Kconfig| 9 + > drivers/soc/bcm/Makefile | 1 + > drivers/soc/bcm/raspberrypi-power.c| 247 > + > include/dt-bindings/soc/raspberrypi-power.h| 41 > include/soc/bcm2835/raspberrypi-firmware.h | 2 + > 10 files changed, 361 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt > create mode 100644 drivers/soc/bcm/Kconfig > create mode 100644 drivers/soc/bcm/Makefile > create mode 100644 drivers/soc/bcm/raspberrypi-power.c > create mode 100644 include/dt-bindings/soc/raspberrypi-power.h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/5] ARM: dts: ifc6410: enable pcie dt node for this board
On Thu 03 Dec 05:35 PST 2015, Stanimir Varbanov wrote:
> Enable pcie dt node and fill pcie dt node with regulator, pinctrl
> and reset gpio, to use the pcie on the ifc6410 board.
>
> Signed-off-by: Stanimir Varbanov
> ---
> arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> index 11ac608b6d50..f203b94ee460 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> @@ -47,6 +47,18 @@
> bias-disable;
> };
> };
> +
> + pcie_pins: pcie_pinmux {
> + mux {
> + pins = "gpio27";
> + function = "gpio";
> + };
> + conf {
> + pins = "gpio27";
> + drive-strength = <12>;
> + bias-disable;
> + };
> + };
> };
>
> rpm@108000 {
> @@ -123,6 +135,10 @@
> pm8921_lvs1: lvs1 {
> bias-pull-down;
> };
> +
> + pm8921_lvs6: lvs6 {
> + bias-pull-down;
> + };
Please don't duplicate the labels in the dts files.
> };
> };
>
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: TS-4800: use weim IP to map the FPGA
Previously, the device tree mapped the FPGA like any other IPs inside
the SoC, but it is actually mapped through the WEIM (Wireless External
Interface Module). This patch updates the device tree to make use of it.
About the timings: in the image provided by the manufacturer, only
CS0GCR1 is changed. The other values are the default ones, but the WEIM
bindings expect them to be all explicitly set in the device tree, so I
just put the default values in the dt.
Signed-off-by: Damien Riegel
---
arch/arm/boot/dts/imx51-ts4800.dts | 60 +-
1 file changed, 39 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-ts4800.dts
b/arch/arm/boot/dts/imx51-ts4800.dts
index 64ac55c..83352cb 100644
--- a/arch/arm/boot/dts/imx51-ts4800.dts
+++ b/arch/arm/boot/dts/imx51-ts4800.dts
@@ -21,27 +21,6 @@
reg = <0x9000 0x1000>;
};
- soc {
- fpga {
- compatible = "simple-bus";
- reg = <0xb000 0x1d000>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- syscon: syscon@b001 {
- compatible = "syscon", "simple-mfd";
- reg = <0xb001 0x3d>;
- reg-io-width = <2>;
-
- wdt@e {
- compatible = "technologic,ts4800-wdt";
- syscon = <&syscon 0xe>;
- };
- };
- };
- };
-
clocks {
ckih1 {
clock-frequency = <22579200>;
@@ -99,6 +78,33 @@
status = "okay";
};
+&weim {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_weim>;
+ status = "okay";
+
+ fpga@0 {
+ compatible = "simple-bus";
+ fsl,weim-cs-timing = <0x0061008F 0x0002 0x1c022000
+ 0x 0x1c092480 0x>;
+ reg = <0 0x000 0x1d000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0 0x1d000>;
+
+ syscon: syscon@b001 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x1 0x3d>;
+ reg-io-width = <2>;
+
+ wdt@e {
+ compatible = "technologic,ts4800-wdt";
+ syscon = <&syscon 0xe>;
+ };
+ };
+ };
+};
+
&iomuxc {
pinctrl_ecspi1: ecspi1grp {
fsl,pins = <
@@ -173,4 +179,16 @@
MX51_PAD_EIM_D26__UART3_TXD 0x1c5
>;
};
+
+ pinctrl_weim: weimgrp {
+ fsl,pins = <
+ MX51_PAD_EIM_DTACK__EIM_DTACK 0x85
+ MX51_PAD_EIM_CS0__EIM_CS0 0x0
+ MX51_PAD_EIM_CS1__EIM_CS1 0x0
+ MX51_PAD_EIM_EB0__EIM_EB0 0x85
+ MX51_PAD_EIM_EB1__EIM_EB1 0x85
+ MX51_PAD_EIM_OE__EIM_OE 0x85
+ MX51_PAD_EIM_LBA__EIM_LBA 0x85
+ >;
+ };
};
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: TS-4800: drop uart rts/cts pin reservations
These pins are actually not routed for UARTs, they should not be reserved. Signed-off-by: Damien Riegel --- arch/arm/boot/dts/imx51-ts4800.dts | 4 1 file changed, 4 deletions(-) diff --git a/arch/arm/boot/dts/imx51-ts4800.dts b/arch/arm/boot/dts/imx51-ts4800.dts index f1317f7..64ac55c 100644 --- a/arch/arm/boot/dts/imx51-ts4800.dts +++ b/arch/arm/boot/dts/imx51-ts4800.dts @@ -157,8 +157,6 @@ fsl,pins = < MX51_PAD_UART1_RXD__UART1_RXD 0x1c5 MX51_PAD_UART1_TXD__UART1_TXD 0x1c5 - MX51_PAD_UART1_RTS__UART1_RTS 0x1c5 - MX51_PAD_UART1_CTS__UART1_CTS 0x1c5 >; }; @@ -173,8 +171,6 @@ fsl,pins = < MX51_PAD_EIM_D25__UART3_RXD 0x1c5 MX51_PAD_EIM_D26__UART3_TXD 0x1c5 - MX51_PAD_EIM_D27__UART3_RTS 0x1c5 - MX51_PAD_EIM_D24__UART3_CTS 0x1c5 >; }; }; -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: imx7d: add arch timer
On Thu, Dec 17, 2015 at 2:45 PM, Stefan Agner wrote:
> On 2015-12-10 15:12, frank...@freescale.com wrote:
>> From: Frank Li
>>
>> add cortex a7 arch timer.
>> uboot v2016.01-rc2 supported psci basic support.
>> smp can be supported by psci
>
> This sounds a bit overly simplified log message. I am not very into this
> PSCI topic, is this a prerequisit for the ARM arch timers? Maybe you
> could elaborate that a bit more.
No.
But according to previous discussion. Shawn want us to use psci to enable
second core. We need enable arch timer if second core enabled.
>
> Also, I would prefer full sentences and commonly used spellings such as
> Cortex-A7, U-Boot etc...
>
> --
> Stefan
>
>>
>> Signed-off-by: Frank Li
>> ---
>> arch/arm/boot/dts/imx7d.dtsi | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
>> index 489604a..a621af6 100644
>> --- a/arch/arm/boot/dts/imx7d.dtsi
>> +++ b/arch/arm/boot/dts/imx7d.dtsi
>> @@ -119,6 +119,15 @@
>> clock-output-names = "osc";
>> };
>>
>> + timer {
>> + compatible = "arm,armv7-timer";
>> + interrupts = > IRQ_TYPE_LEVEL_LOW)>,
>> + > IRQ_TYPE_LEVEL_LOW)>,
>> + > IRQ_TYPE_LEVEL_LOW)>,
>> + > IRQ_TYPE_LEVEL_LOW)>;
>> + interrupt-parent = <&intc>;
>> + };
>> +
>> etr@30086000 {
>> compatible = "arm,coresight-tmc", "arm,primecell";
>> reg = <0x30086000 0x1000>;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
Hello.
On 12/17/2015 05:34 AM, Chanwoo Choi wrote:
On 2015년 12월 17일 03:07, Sergei Shtylyov wrote:
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov
---
Changes in version 3:
- reformatted the change log.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
entry, the driver heading comment, the module description, and the change
log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig |8
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 153
4 files changed, 183 insertions(+)
[snip]
+ return 0;
+}
+
+static int max3355_remove(struct platform_device *pdev)
+{
+ struct max3355_data *data = platform_get_drvdata(pdev);
+
+ gpiod_set_value_cansleep(data->shdn_gpiod, 0);
Don't need to handle the 'shdn' gpio on resume/suspend funtcion?
But, if the interrput of id gpio is used for wakeup source,
there is no reason to handle it for suspend mode.
You told me to pass IRQF_NO_SUSPEND to devm_request_threaded_irq(), didn't
you?
[snip]
Thanks,
Chanwoo Choi
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/5] PCI: qcom: Add Qualcomm PCIe controller driver
On Thu, Dec 17, 2015 at 03:18:43PM +0200, Stanimir Varbanov wrote: > Bjorn, thanks for the comments! > > On 12/16/2015 11:53 PM, Bjorn Helgaas wrote: > > On Thu, Dec 03, 2015 at 03:35:22PM +0200, Stanimir Varbanov wrote: > >> From: Stanimir Varbanov > >> > >> The PCIe driver reuse the Designware common code for host > >> and MSI initialization, and also program the Qualcomm > >> application specific registers. > >> > >> Signed-off-by: Stanimir Varbanov > >> Signed-off-by: Stanimir Varbanov > >> --- > >> MAINTAINERS |7 + > >> drivers/pci/host/Kconfig | 10 + > >> drivers/pci/host/Makefile|1 + > >> drivers/pci/host/pcie-qcom.c | 624 > >> ++ > > > >> +#define PCIE20_CAP0x70 > >> +#define PCIE20_CAP_LINKCTRLSTATUS (PCIE20_CAP + 0x10) > >> +#define PCIE20_CAP_LINKCTRLSTATUS_LINK_UP BIT(29) > > > > This looks like it could be referring to a standard PCIe Capability; > > could you use the existing PCI_EXP_LNKSTA and PCI_EXP_LNKSTA_DLLLA > > symbols here? And readw() instead of readl()? > > Yes, that is possible but I still need to keep PCIE20_CAP capabilities > offset. Great, thanks! I think that will help keep generic PCIe things from looking like they're special implementation-specific things. Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] Raspberry Pi power domains
On 17 December 2015 at 21:11, Arnd Bergmann wrote: > On Thursday 17 December 2015 11:03:47 Eric Anholt wrote: >> >> >> >> .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt | 47 >> >> arch/arm/boot/dts/bcm2835-rpi.dtsi | 11 + >> >> arch/arm/boot/dts/bcm2835.dtsi | 2 +- >> >> arch/arm/mach-bcm/Kconfig | 10 + >> >> arch/arm/mach-bcm/Makefile | 1 + >> >> arch/arm/mach-bcm/raspberrypi-power.c | 247 >> >> + >> >> include/dt-bindings/arm/raspberrypi-power.h| 41 >> >> include/soc/bcm2835/raspberrypi-firmware.h | 2 + >> >> 8 files changed, 360 insertions(+), 1 deletion(-) >> >> create mode 100644 >> >> Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt >> >> create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c >> >> create mode 100644 include/dt-bindings/arm/raspberrypi-power.h >> >> >> >> -- >> >> 2.6.2 >> >> >> > >> > Besides a nitpick for patch2, I would also reverse the order of patch3 >> > and patch2. DT docs should go in before the actual parsing of the new >> > bindings/compatibles. >> > >> > Anyway, for the hole series, you may add my: >> > >> > Reviewed-by: Ulf Hansson >> >> Would your tree be pulling the series (since it's power domains), or >> should I (since it's SOC stuff)? >> > > All of the above files go through the arm-soc tree by default. That should work as I don't see any other dependency, unless Eric/Alexander think there is. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 v5] enable to use thermal-zone on r8a7790/1
On Tue, Dec 15, 2015 at 01:16:20AM +, Kuninori Morimoto wrote: > > Hi > > These are v5 of thermal-zone support for r8a7790/r8a7791. > > Kuninori Morimoto (8): > 1) thermal: rcar: move rcar_thermal_dt_ids to upside > 2) thermal: rcar: check every rcar_thermal_update_temp() return value > 3) thermal: rcar: check irq possibility in rcar_thermal_irq_xxx() > 4) thermal: rcar: rcar_thermal_get_temp() return error if strange temp Applied the four above > 5) thermal: rcar: enable to use thermal-zone on DT This one requires further discussion. > 6) ARM: shmobile: r8a7790: enable to use thermal-zone > 7) ARM: shmobile: r8a7791: enable to use thermal-zone These two will go on other tree, but depend on 5. So, still on hold. > 8) thermal: of-thermal: of_thermal_set_trip_temp() call > thermal_zone_device_update() > Applied number 8 too. BR, Eduardo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/macb: Update device tree binding for resetting PHY using GPIO
From: Gregory CLEMENT Date: Thu, 17 Dec 2015 10:51:04 +0100 > Instead of being at the MAC level the reset gpio preperty is moved at the > PHY child node level. It is still managed by the MAC, but from the point > of view of the binding it make more sense to be part of the PHY node. > > This commit also fixes a build errors if GPIOLIB is not selected. > > Signed-off-by: Gregory CLEMENT Applied to net-next, thanks. Please be explicit in your patch postings what tree you are targetting a change at. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: imx7d: add arch timer
On 2015-12-10 15:12, frank...@freescale.com wrote:
> From: Frank Li
>
> add cortex a7 arch timer.
> uboot v2016.01-rc2 supported psci basic support.
> smp can be supported by psci
This sounds a bit overly simplified log message. I am not very into this
PSCI topic, is this a prerequisit for the ARM arch timers? Maybe you
could elaborate that a bit more.
Also, I would prefer full sentences and commonly used spellings such as
Cortex-A7, U-Boot etc...
--
Stefan
>
> Signed-off-by: Frank Li
> ---
> arch/arm/boot/dts/imx7d.dtsi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> index 489604a..a621af6 100644
> --- a/arch/arm/boot/dts/imx7d.dtsi
> +++ b/arch/arm/boot/dts/imx7d.dtsi
> @@ -119,6 +119,15 @@
> clock-output-names = "osc";
> };
>
> + timer {
> + compatible = "arm,armv7-timer";
> + interrupts = IRQ_TYPE_LEVEL_LOW)>,
> + IRQ_TYPE_LEVEL_LOW)>,
> + IRQ_TYPE_LEVEL_LOW)>,
> + IRQ_TYPE_LEVEL_LOW)>;
> + interrupt-parent = <&intc>;
> + };
> +
> etr@30086000 {
> compatible = "arm,coresight-tmc", "arm,primecell";
> reg = <0x30086000 0x1000>;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8 v5] thermal: rcar: enable to use thermal-zone on DT
On Tue, Dec 15, 2015 at 01:18:39AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch enables to use thermal-zone on DT if it was call as > "renesas,rcar-thermal-gen2". > Previous style is still supported by "renesas,rcar-thermal". Could you please include also an explanation why you need to keep the support of 'previous style'? BR, Eduardo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] Raspberry Pi power domains
On Thursday 17 December 2015 11:03:47 Eric Anholt wrote: > >> > >> .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt | 47 > >> arch/arm/boot/dts/bcm2835-rpi.dtsi | 11 + > >> arch/arm/boot/dts/bcm2835.dtsi | 2 +- > >> arch/arm/mach-bcm/Kconfig | 10 + > >> arch/arm/mach-bcm/Makefile | 1 + > >> arch/arm/mach-bcm/raspberrypi-power.c | 247 > >> + > >> include/dt-bindings/arm/raspberrypi-power.h| 41 > >> include/soc/bcm2835/raspberrypi-firmware.h | 2 + > >> 8 files changed, 360 insertions(+), 1 deletion(-) > >> create mode 100644 > >> Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt > >> create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c > >> create mode 100644 include/dt-bindings/arm/raspberrypi-power.h > >> > >> -- > >> 2.6.2 > >> > > > > Besides a nitpick for patch2, I would also reverse the order of patch3 > > and patch2. DT docs should go in before the actual parsing of the new > > bindings/compatibles. > > > > Anyway, for the hole series, you may add my: > > > > Reviewed-by: Ulf Hansson > > Would your tree be pulling the series (since it's power domains), or > should I (since it's SOC stuff)? > All of the above files go through the arm-soc tree by default. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Fix a trivial typo and support rk3228/rk3399 SoCs for thermal driver.
Hello, On Thu, Dec 03, 2015 at 04:48:38PM +0800, Caesar Wang wrote: > This series pacthes to support the next soc for this thermal driver. > I don't add the dts thermal data since these SoCs have *_not_* land > in this mainline. I believe these SoCs dts will land in this mainline > lately, > then I will add the thermal data for Heiko. > > This series patches can apply into Eduardo branch. > https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git > > Also, this series pacthes have built on github branch. > https://github.com/rockchip-linux/kernel/commits/develop4.4 > > PATCH[1/5]: > That's bit ugly typo, sorry for sending again :(. > > PATCH[2/5]: > To fix a build warning came from Dan Carpenter report smatch check, > Thanks. :) > > PATCH[3/5]: > Add the rk3228/rk3399 SoCs compatible for dt-bindings. > > PATCH[4/5]: > Add the rk3228 SoCs for thermal driver. > > PATCH[5/5]: > Add the rk3399 SoCs for thermal driver based on PATCH[4/5]. I applied all but 2/5. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/4] Documentation, dt, arm64/arm: dt bindings for numa.
Hi, On Fri, Dec 11, 2015 at 08:11:07PM +0530, Ganapatrao Kulkarni wrote: > On Fri, Dec 11, 2015 at 7:23 PM, Mark Rutland wrote: > > Hi, > > > > On Tue, Nov 17, 2015 at 10:50:41PM +0530, Ganapatrao Kulkarni wrote: > >> DT bindings for numa mapping of memory, cores and IOs. > >> > >> Reviewed-by: Robert Richter > >> Signed-off-by: Ganapatrao Kulkarni > > > > Overall this looks good to me. However, I have a couple of concerns. > thanks. [...] > >> +== > >> +2 - numa-node-id > >> +== > >> +The device node property numa-node-id describes numa domains within a > >> +machine. This property can be used in device nodes like cpu, memory, bus > >> and > >> +devices to map to respective numa nodes. > >> + > >> +numa-node-id property is a 32-bit integer which defines numa node id to > >> which > >> +this device node has numa domain association. > > > > I'd prefer if the above two paragraphs were replaced with: > > > > For the purpose of identification, each NUMA node is associated > > with a unique token known as a node id. For the purpose of this > > binding a node id is a 32-bit integer. > > > > A device node is associated with a NUMA node by the presence of > > a numa-node-id property which contains the node id of the > > device. > ok, will do. [...] > >> +== > >> +3 - distance-map > >> +== > >> + > >> +The device tree node distance-map describes the relative > >> +distance (memory latency) between all numa nodes. > > > > Is this not a combined approximation for latency and bandwidth? > AFAIK, it is to represent inter-node memory access latency. > > > >> +- compatible : Should at least contain "numa,distance-map-v1". > > > > Please use "numa-distance-map-v1", as "numa" is not a vendor. > ok > > > >> +- distance-matrix > >> + This property defines a matrix to describe the relative distances > >> + between all numa nodes. > >> + It is represented as a list of node pairs and their relative distance. > >> + > >> + Note: > >> + 1. Each entry represents distance from first node to second node. > >> + 2. If both directions between 2 nodes have the same distance, only > >> +one entry is required. > > > > I still don't understand what direction means in this context. Are there > > systems (of any architecture) which don't have symmetric distances? > > Which accesses does this apply differently to? > > > > Given that, I think that it might be best to explicitly call out > > distances as being equal, and leave any directionality for a later > > revision of the binding when we have some semantics for directionality. > agreed, given that there is no know system to substantiate dual direction, > let us not explicit about direction. Regarding your comment in [1], I was expecting a respin of this series with the above comments addressed. I will not provide an ack until I've seen that. Additional concerns below also apply. > >> + 2. distance-matrix shold have entries in lexicographical ascending > >> order of nodes. > >> + 3. There must be only one Device node distance-map and must reside > >> in the root node. > >> + > >> +Example: > >> + 4 nodes connected in mesh/ring topology as below, > >> + > >> + 0___20__1 > >> + | | > >> + | | > >> + 20| |20 > >> + | | > >> + | | > >> + |___| > >> + 3 20 2 > >> + > >> + if relative distance for each hop is 20, > >> + then inter node distance would be for this topology will be, > >> + 0 -> 1 = 20 > >> + 1 -> 2 = 20 > >> + 2 -> 3 = 20 > >> + 3 -> 0 = 20 > >> + 0 -> 2 = 40 > >> + 1 -> 3 = 40 > > > > How is this scaled relative to a local access? > this is based on representing local distance with 10 and > all inter-node latency being represented as multiple of 10. > > > > > Do we assume that a local access has value 1, e.g. each hop takes 20x a > > local access in this example? > The local distance is represented as 10, this is fixed and same as in ACPI. > Inter-node distance can be any number greater than 10. > this information can be added here to make it clear. This seems rather arbitrary. Why can we not define the local distance in the DT? I appreciate that the value is hard-coded for ACPI, but we don't have to copy that limitation. I'm not sure if asymmetric local distances matter. Thanks, Mark. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394634.html -- To unsubscribe from this list: send the line "unsu
Re: [PATCH v3 0/4] Raspberry Pi power domains
Ulf Hansson writes: > On 15 December 2015 at 22:40, Eric Anholt wrote: >> Since the pm_genpd_exit() patch is still going through review, and >> other drivers in the tree just ignore the error cases, Ulf offered to >> merge the series as a builtin driver not depending on that interface. >> We still avoid dangling pointer references, by just continuing with >> probing if of_genpd_add_provider_onecell() fails. We can easily go >> back and update the driver when a pm_genpd_exit() lands. >> >> Alexander Aring (3): >> ARM: bcm2835: add rpi power domain driver >> dt-bindings: add rpi power domain driver bindings >> ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. >> >> Eric Anholt (1): >> ARM: bcm2835: Define two new packets from the latest firmware. >> >> .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt | 47 >> arch/arm/boot/dts/bcm2835-rpi.dtsi | 11 + >> arch/arm/boot/dts/bcm2835.dtsi | 2 +- >> arch/arm/mach-bcm/Kconfig | 10 + >> arch/arm/mach-bcm/Makefile | 1 + >> arch/arm/mach-bcm/raspberrypi-power.c | 247 >> + >> include/dt-bindings/arm/raspberrypi-power.h| 41 >> include/soc/bcm2835/raspberrypi-firmware.h | 2 + >> 8 files changed, 360 insertions(+), 1 deletion(-) >> create mode 100644 >> Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt >> create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c >> create mode 100644 include/dt-bindings/arm/raspberrypi-power.h >> >> -- >> 2.6.2 >> > > Besides a nitpick for patch2, I would also reverse the order of patch3 > and patch2. DT docs should go in before the actual parsing of the new > bindings/compatibles. > > Anyway, for the hole series, you may add my: > > Reviewed-by: Ulf Hansson Would your tree be pulling the series (since it's power domains), or should I (since it's SOC stuff)? signature.asc Description: PGP signature
Re: [PATCH v5 4/5] ARM: dts: DRA7: add entry for qspi mmap region
* Rob Herring [151211 07:10]: > On Fri, Dec 11, 2015 at 09:39:59AM +0530, Vignesh R wrote: > > Add qspi memory mapped region entries for DRA7xx based SoCs. Also, > > update the binding documents for the controller to document this change. > > > > Signed-off-by: Vignesh R > > Acked-by: Rob Herring Vignes, are patches 4 and 5 safe to apply separately already or do things break if we do that? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] arm64, numa: adding numa support for arm64 platforms.
Thanks Will for the review. On Thu, Dec 17, 2015 at 10:41 PM, Will Deacon wrote: > Hello, > > This all looks pretty reasonable, but I'd like to see an Ack from a > devicetree maintainer on the binding before I merge anything (and I see > that there are outstanding comments from Rutland on that). IIUC, there are no open comments for the binding. Mark Rutland: please let me know, if there any open comments. otherwise, can you please Ack the binding. > > On Tue, Nov 17, 2015 at 10:50:40PM +0530, Ganapatrao Kulkarni wrote: >> Adding numa support for arm64 based platforms. >> This patch adds by default the dummy numa node and >> maps all memory and cpus to node 0. >> using this patch, numa can be simulated on single node arm64 platforms. >> >> Reviewed-by: Robert Richter >> Signed-off-by: Ganapatrao Kulkarni >> --- >> arch/arm64/Kconfig | 25 +++ >> arch/arm64/include/asm/mmzone.h | 17 ++ >> arch/arm64/include/asm/numa.h | 47 + >> arch/arm64/kernel/setup.c | 4 + >> arch/arm64/kernel/smp.c | 2 + >> arch/arm64/mm/Makefile | 1 + >> arch/arm64/mm/init.c| 30 +++- >> arch/arm64/mm/numa.c| 384 >> >> 8 files changed, 506 insertions(+), 4 deletions(-) >> create mode 100644 arch/arm64/include/asm/mmzone.h >> create mode 100644 arch/arm64/include/asm/numa.h >> create mode 100644 arch/arm64/mm/numa.c >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index 9ac16a4..7d8fb42 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -71,6 +71,7 @@ config ARM64 >> select HAVE_GENERIC_DMA_COHERENT >> select HAVE_HW_BREAKPOINT if PERF_EVENTS >> select HAVE_MEMBLOCK >> + select HAVE_MEMBLOCK_NODE_MAP if NUMA >> select HAVE_PATA_PLATFORM >> select HAVE_PERF_EVENTS >> select HAVE_PERF_REGS >> @@ -482,6 +483,30 @@ config HOTPLUG_CPU >> Say Y here to experiment with turning CPUs off and on. CPUs >> can be controlled through /sys/devices/system/cpu. >> >> +# Common NUMA Features >> +config NUMA >> + bool "Numa Memory Allocation and Scheduler Support" >> + depends on SMP >> + help >> + Enable NUMA (Non Uniform Memory Access) support. >> + >> + The kernel will try to allocate memory used by a CPU on the >> + local memory controller of the CPU and add some more >> + NUMA awareness to the kernel. > > I appreciate that this is copied from x86, but what exactly do you mean > by "memory controller" here? ok, it is fair enough to say local memory. > >> diff --git a/arch/arm64/include/asm/mmzone.h >> b/arch/arm64/include/asm/mmzone.h >> new file mode 100644 >> index 000..6ddd468 >> --- /dev/null >> +++ b/arch/arm64/include/asm/mmzone.h >> @@ -0,0 +1,17 @@ >> +#ifndef __ASM_ARM64_MMZONE_H_ >> +#define __ASM_ARM64_MMZONE_H_ > > Please try to follow the standard naming for header guards under arm64 > (yes, it's not perfect, but we've made some effort for consistency). sure, will follow as in other code. > >> + >> +#ifdef CONFIG_NUMA >> + >> +#include >> +#include >> + >> +#include >> +#include >> + >> +extern struct pglist_data *node_data[]; >> + >> +#define NODE_DATA(nid) (node_data[(nid)]) > > This is the same as m32r, metag, parisc, powerpc, s390, sh, sparc, tile > and x86. Can we make this the default in the core code instead and then > replace this header file with asm-generic or something? IIUC, it is same in most but not in all arch. > >> + >> +#endif /* CONFIG_NUMA */ >> +#endif /* __ASM_ARM64_MMZONE_H_ */ >> diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h >> new file mode 100644 >> index 000..c00f3a4 >> --- /dev/null >> +++ b/arch/arm64/include/asm/numa.h >> @@ -0,0 +1,47 @@ >> +#ifndef _ASM_NUMA_H >> +#define _ASM_NUMA_H > > Same comment on the guards. ok > >> +#include >> +#include >> + >> +#ifdef CONFIG_NUMA >> + >> +#define NR_NODE_MEMBLKS (MAX_NUMNODES * 2) > > This is only used by the ACPI code afaict, so maybe include it when you > add that? ok > >> +#define ZONE_ALIGN (1UL << (MAX_ORDER + PAGE_SHIFT)) > > Where is this used? sorry, was used in v6, missed to delete. > >> + >> +/* currently, arm64 implements flat NUMA topology */ >> +#define parent_node(node)(node) >> + >> +extern int __node_distance(int from, int to); >> +#define node_distance(a, b) __node_distance(a, b) >> + >> +/* dummy definitions for pci functions */ >> +#define pcibus_to_node(node) 0 >> +#define cpumask_of_pcibus(bus) 0 > > There's a bunch of these dummy definitions already available in > asm-generic/topology.h. Can we use those instead of rolling our own > please? > >> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c >> index 17bf39a..8dc9c5d 100644 >> --- a/arch/arm64/mm/init.c >> +++ b/arch/arm64/mm/init.c >> @@ -37,6 +37,7 @@ >> >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -77,6 +78
Re: [PATCH 2/5] ARM: dts: cm-t335: add support for SBC-T335
* Rob Herring [151213 17:26]: > On Sun, Dec 13, 2015 at 10:55:36AM +0200, Uri Mashiach wrote: > > Add basic support for the SBC-T335. > > > > CompuLab SBC-T335 is a single baseboard computer. > > The SBC-T335 is based on the Texas Instruments Cortex-A8 Sitara AM3354 > > SoC. > > > > Signed-off-by: Uri Mashiach > > Acked-by: Igor Grinberg > > Acked-by: Rob Herring Thanks applying the whole series into omap-for-v4.5/dt. Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/19] ARM: dts: omap: replace legacy *,wakeup property with wakeup-source
* Sudeep Holla [151215 08:37]: > > > On 21/10/15 11:10, Sudeep Holla wrote: > >Though the keyboard and other driver will continue to support the legacy > >"gpio-key,wakeup", "linux,wakeup" boolean property to enable the wakeup > >source, "wakeup-source" is the new standard binding. > > > >This patch replaces all the legacy wakeup properties with the unified > >"wakeup-source" property in order to avoid any futher copy-paste > >duplication. > > > >Cc: "Benoît Cousson" > >Cc: Tony Lindgren > > Ping, do you prefer taking via your tree or should I send to armsoc > directly ? Applying this one too thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/19] ARM: dts: am335x: replace gpio-key,wakeup with wakeup-source property
* Sudeep Holla [151215 08:33]: > > > On 21/10/15 11:10, Sudeep Holla wrote: > >Though the keyboard driver for GPIO buttons(gpio-keys) will continue to > >check for/support the legacy "gpio-key,wakeup" boolean property to > >enable gpio buttons as wakeup source, "wakeup-source" is the new > >standard binding. > > > >This patch replaces the legacy "gpio-key,wakeup" with the unified > >"wakeup-source" property in order to avoid any futher copy-paste > >duplication. > > > >Cc: "Benoît Cousson" > >Cc: Tony Lindgren > > Ping, do you prefer taking via your tree or should I send to armsoc > directly ? Sorry I did not realized you're waiting for me to pick this one, applying into omap-for-v4.5/dt thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] of: fix declaration of of_io_request_and_map
On Tue, Dec 8, 2015 at 2:47 AM, Sudip Mukherjee
wrote:
> We are having build failure with linux-next for sparc allmodconfig with
> the error messages:
>
> drivers/built-in.o: In function `meson6_timer_init':
> meson6_timer.c:(.init.text+0x5fe8): undefined reference to
> `of_io_request_and_map'
> drivers/built-in.o: In function `mtk_timer_init':
> mtk_timer.c:(.init.text+0x6af0): undefined reference to
> `of_io_request_and_map'
> drivers/built-in.o: In function `asm9260_timer_init':
> asm9260_timer.c:(.init.text+0x6c48): undefined reference to
> `of_io_request_and_map'
>
> CONFIG_OF is defined for sparc so it is expected that we have a
> definition of of_io_request_and_map() but of/address.c is only compiled
> if it is !SPARC. In other words, CONFIG_OF_ADDRESS is not defined for
> sparc so we get the build failure.
>
> Fixes: e572f844ca66 ("clocksource/drivers/meson6: Add the COMPILE_TEST
> option")
> Fixes: bec8c4617611 ("clocksource/drivers/mediatek: Add the COMPILE_TEST
> option")
> Fixes: 4a373b45f94a ("clocksource/drivers/asm9260: Add the COMPILE_TEST
> option")
> Cc: Daniel Lezcano
> Signed-off-by: Sudip Mukherjee
Moved the include out of the ifdefs and applied, thanks.
Rob
> ---
>
> v1: had a complicated set of #ifdefs
> v2: i messed up and resulted in build failure of some other arch where
> CONFIG_OF is not defined.
> v3: tested with allmodconfig of x86_64, defconfig of alpha and mips.
> v4: changed subject and commit message. And the of_io_request_and_map()
> is moved under existing #ifdef instead of defining one more section.
>
>
> include/linux/of_address.h | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 507daad..4d6c50a 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -36,6 +36,8 @@ extern struct device_node *of_find_matching_node_by_address(
> const struct of_device_id *matches,
> u64 base_address);
> extern void __iomem *of_iomap(struct device_node *device, int index);
> +void __iomem *of_io_request_and_map(struct device_node *device,
> + int index, const char *name);
>
> /* Extract an address from a device, returns the region size and
> * the address space flags too. The PCI version uses a BAR number
> @@ -58,6 +60,14 @@ extern int of_dma_get_range(struct device_node *np, u64
> *dma_addr,
> extern bool of_dma_is_coherent(struct device_node *np);
> #else /* CONFIG_OF_ADDRESS */
>
> +#include
> +
> +static inline void __iomem *of_io_request_and_map(struct device_node *device,
> + int index, const char *name)
> +{
> + return IOMEM_ERR_PTR(-EINVAL);
> +}
> +
> static inline u64 of_translate_address(struct device_node *np,
>const __be32 *addr)
> {
> @@ -112,8 +122,6 @@ static inline bool of_dma_is_coherent(struct device_node
> *np)
> extern int of_address_to_resource(struct device_node *dev, int index,
> struct resource *r);
> void __iomem *of_iomap(struct device_node *node, int index);
> -void __iomem *of_io_request_and_map(struct device_node *device,
> - int index, const char *name);
> #else
>
> #include
> @@ -128,12 +136,6 @@ static inline void __iomem *of_iomap(struct device_node
> *device, int index)
> {
> return NULL;
> }
> -
> -static inline void __iomem *of_io_request_and_map(struct device_node *device,
> - int index, const char *name)
> -{
> - return IOMEM_ERR_PTR(-EINVAL);
> -}
> #endif
>
> #if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_PCI)
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v02 0/2] ARM: DTS: am33xx/am437x: Use the new eDMA bindings
* Peter Ujfalusi [151217 05:33]: > Hi, > > Changes since v1: > - Updated to use the non 16bit arrays [1] > - send the two patch as a series > > [1] > As it has been discussed earlier: > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html > > the DT bindings has been changes compared to what we had in 4.4-rc1: the > arrays > now don't have the 16bit type. > The changes are now merged to mainline and Vinod provided us a branch: > > git://git.infradead.org/users/vkoul/slave-dma.git fix/edma > > Which is based on 4.4-rc1 and only contains the two patch for changing the > eDMA > bindings. Great, I'll merge the fix/edma also into omap-for-v4.5/dt and apply your two patches. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] arm64, numa: adding numa support for arm64 platforms.
Hello,
This all looks pretty reasonable, but I'd like to see an Ack from a
devicetree maintainer on the binding before I merge anything (and I see
that there are outstanding comments from Rutland on that).
On Tue, Nov 17, 2015 at 10:50:40PM +0530, Ganapatrao Kulkarni wrote:
> Adding numa support for arm64 based platforms.
> This patch adds by default the dummy numa node and
> maps all memory and cpus to node 0.
> using this patch, numa can be simulated on single node arm64 platforms.
>
> Reviewed-by: Robert Richter
> Signed-off-by: Ganapatrao Kulkarni
> ---
> arch/arm64/Kconfig | 25 +++
> arch/arm64/include/asm/mmzone.h | 17 ++
> arch/arm64/include/asm/numa.h | 47 +
> arch/arm64/kernel/setup.c | 4 +
> arch/arm64/kernel/smp.c | 2 +
> arch/arm64/mm/Makefile | 1 +
> arch/arm64/mm/init.c| 30 +++-
> arch/arm64/mm/numa.c| 384
>
> 8 files changed, 506 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm64/include/asm/mmzone.h
> create mode 100644 arch/arm64/include/asm/numa.h
> create mode 100644 arch/arm64/mm/numa.c
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9ac16a4..7d8fb42 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -71,6 +71,7 @@ config ARM64
> select HAVE_GENERIC_DMA_COHERENT
> select HAVE_HW_BREAKPOINT if PERF_EVENTS
> select HAVE_MEMBLOCK
> + select HAVE_MEMBLOCK_NODE_MAP if NUMA
> select HAVE_PATA_PLATFORM
> select HAVE_PERF_EVENTS
> select HAVE_PERF_REGS
> @@ -482,6 +483,30 @@ config HOTPLUG_CPU
> Say Y here to experiment with turning CPUs off and on. CPUs
> can be controlled through /sys/devices/system/cpu.
>
> +# Common NUMA Features
> +config NUMA
> + bool "Numa Memory Allocation and Scheduler Support"
> + depends on SMP
> + help
> + Enable NUMA (Non Uniform Memory Access) support.
> +
> + The kernel will try to allocate memory used by a CPU on the
> + local memory controller of the CPU and add some more
> + NUMA awareness to the kernel.
I appreciate that this is copied from x86, but what exactly do you mean
by "memory controller" here?
> diff --git a/arch/arm64/include/asm/mmzone.h b/arch/arm64/include/asm/mmzone.h
> new file mode 100644
> index 000..6ddd468
> --- /dev/null
> +++ b/arch/arm64/include/asm/mmzone.h
> @@ -0,0 +1,17 @@
> +#ifndef __ASM_ARM64_MMZONE_H_
> +#define __ASM_ARM64_MMZONE_H_
Please try to follow the standard naming for header guards under arm64
(yes, it's not perfect, but we've made some effort for consistency).
> +
> +#ifdef CONFIG_NUMA
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +extern struct pglist_data *node_data[];
> +
> +#define NODE_DATA(nid) (node_data[(nid)])
This is the same as m32r, metag, parisc, powerpc, s390, sh, sparc, tile
and x86. Can we make this the default in the core code instead and then
replace this header file with asm-generic or something?
> +
> +#endif /* CONFIG_NUMA */
> +#endif /* __ASM_ARM64_MMZONE_H_ */
> diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
> new file mode 100644
> index 000..c00f3a4
> --- /dev/null
> +++ b/arch/arm64/include/asm/numa.h
> @@ -0,0 +1,47 @@
> +#ifndef _ASM_NUMA_H
> +#define _ASM_NUMA_H
Same comment on the guards.
> +#include
> +#include
> +
> +#ifdef CONFIG_NUMA
> +
> +#define NR_NODE_MEMBLKS (MAX_NUMNODES * 2)
This is only used by the ACPI code afaict, so maybe include it when you
add that?
> +#define ZONE_ALIGN (1UL << (MAX_ORDER + PAGE_SHIFT))
Where is this used?
> +
> +/* currently, arm64 implements flat NUMA topology */
> +#define parent_node(node)(node)
> +
> +extern int __node_distance(int from, int to);
> +#define node_distance(a, b) __node_distance(a, b)
> +
> +/* dummy definitions for pci functions */
> +#define pcibus_to_node(node) 0
> +#define cpumask_of_pcibus(bus) 0
There's a bunch of these dummy definitions already available in
asm-generic/topology.h. Can we use those instead of rolling our own
please?
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 17bf39a..8dc9c5d 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -37,6 +37,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -77,6 +78,19 @@ static phys_addr_t max_zone_dma_phys(void)
> return min(offset + (1ULL << 32), memblock_end_of_DRAM());
> }
>
> +#ifdef CONFIG_NUMA
> +static void __init zone_sizes_init(unsigned long min, unsigned long max)
> +{
> + unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
> +
> + if (IS_ENABLED(CONFIG_ZONE_DMA))
> + max_zone_pfns[ZONE_DMA] = PFN_DOWN(max_zone_dma_phys());
> + max_zone_pfns[ZONE_NORMAL] = max;
> +
> + free_area_init_nodes(max_zone_pfns);
> +}
This is certainly more readable then the non-numa zone_sizes_init. Is
[PATCH V10 1/7] dma: qcom_bam_dma: move to qcom directory
Creating a QCOM directory for all QCOM DMA source files.
Signed-off-by: Sinan Kaya
Reviewed-by: Andy Gtoss
---
drivers/dma/Kconfig| 11 ++-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 8
drivers/dma/qcom/Makefile | 1 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 ++--
5 files changed, 14 insertions(+), 12 deletions(-)
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index b458475..47b1b98 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -408,15 +408,6 @@ config PXA_DMA
16 to 32 channels for peripheral to memory or memory to memory
transfers.
-config QCOM_BAM_DMA
- tristate "QCOM BAM DMA support"
- depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
- select DMA_ENGINE
- select DMA_VIRTUAL_CHANNELS
- ---help---
- Enable support for the QCOM BAM DMA controller. This controller
- provides DMA capabilities for a variety of on-chip devices.
-
config SIRF_DMA
tristate "CSR SiRFprimaII/SiRFmarco DMA support"
depends on ARCH_SIRF
@@ -527,6 +518,8 @@ config ZX_DMA
# driver files
source "drivers/dma/bestcomm/Kconfig"
+source "drivers/dma/qcom/Kconfig"
+
source "drivers/dma/dw/Kconfig"
source "drivers/dma/hsu/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 7711a71..8dba90d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
obj-$(CONFIG_PL330_DMA) += pl330.o
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
obj-$(CONFIG_PXA_DMA) += pxa_dma.o
-obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
obj-$(CONFIG_RENESAS_DMA) += sh/
obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
@@ -66,4 +65,5 @@ obj-$(CONFIG_TI_EDMA) += edma.o
obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-y += qcom/
obj-y += xilinx/
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
new file mode 100644
index 000..f17c272
--- /dev/null
+++ b/drivers/dma/qcom/Kconfig
@@ -0,0 +1,8 @@
+config QCOM_BAM_DMA
+ tristate "QCOM BAM DMA support"
+ depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ ---help---
+ Enable support for the QCOM BAM DMA controller. This controller
+ provides DMA capabilities for a variety of on-chip devices.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
new file mode 100644
index 000..f612ae3
--- /dev/null
+++ b/drivers/dma/qcom/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom/bam_dma.c
similarity index 99%
rename from drivers/dma/qcom_bam_dma.c
rename to drivers/dma/qcom/bam_dma.c
index 5a250cd..b6f053d 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -49,8 +49,8 @@
#include
#include
-#include "dmaengine.h"
-#include "virt-dma.h"
+#include "../dmaengine.h"
+#include "../virt-dma.h"
struct bam_desc_hw {
u32 addr; /* Buffer physical address */
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V10 5/7] dma: qcom_hidma: implement lower level hardware interface
This patch implements the hardware hooks for the HIDMA channel driver.
The main functions of interest are:
- hidma_ll_init
- hidma_ll_request
- hidma_ll_queue_request
- hidma_ll_hw_start
OS layer calls the hidma_ll_init function during probe to set up the
hardware. At this moment, the number of supported descriptors are also
given. On each request, a descriptor is allocated from the free pool and
filled in with the transfer parameters. Multiple requests can be queued
into the hardware via the OS interface. When client is ready for requests
to be executed, start method is called.
Completions are delivered via callbacks via tasklet.
Signed-off-by: Sinan Kaya
---
drivers/dma/qcom/Makefile | 2 +
drivers/dma/qcom/hidma.h| 2 +-
drivers/dma/qcom/hidma_ll.c | 927
3 files changed, 930 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/qcom/hidma_ll.c
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index bfea699..6bf9267 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,3 +1,5 @@
obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
hdma_mgmt-objs := hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) += hdma.o
+hdma-objs:= hidma_ll.o hidma.o
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index 231e306..1e09d7c 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -37,7 +37,7 @@ struct hidma_tre {
atomic_t allocated; /* if this channel is allocated */
bool queued;/* flag whether this is pending */
u16 status; /* status */
- u32 chidx; /* index of the tre */
+ u32 idx;/* index of the tre */
u32 dma_sig;/* signature of the tre */
const char *dev_name; /* name of the device */
void (*callback)(void *data); /* requester callback */
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
new file mode 100644
index 000..0cd8d70
--- /dev/null
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -0,0 +1,927 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine low level code
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hidma.h"
+
+#define EVRE_SIZE 16 /* each EVRE is 16 bytes */
+
+#define TRCA_CTRLSTS_OFFSET0x0
+#define TRCA_RING_LOW_OFFSET 0x8
+#define TRCA_RING_HIGH_OFFSET 0xC
+#define TRCA_RING_LEN_OFFSET 0x10
+#define TRCA_READ_PTR_OFFSET 0x18
+#define TRCA_WRITE_PTR_OFFSET 0x20
+#define TRCA_DOORBELL_OFFSET 0x400
+
+#define EVCA_CTRLSTS_OFFSET0x0
+#define EVCA_INTCTRL_OFFSET0x4
+#define EVCA_RING_LOW_OFFSET 0x8
+#define EVCA_RING_HIGH_OFFSET 0xC
+#define EVCA_RING_LEN_OFFSET 0x10
+#define EVCA_READ_PTR_OFFSET 0x18
+#define EVCA_WRITE_PTR_OFFSET 0x20
+#define EVCA_DOORBELL_OFFSET 0x400
+
+#define EVCA_IRQ_STAT_OFFSET 0x100
+#define EVCA_IRQ_CLR_OFFSET0x108
+#define EVCA_IRQ_EN_OFFSET 0x110
+
+#define EVRE_CFG_IDX 0
+#define EVRE_LEN_IDX 1
+#define EVRE_DEST_LOW_IDX 2
+#define EVRE_DEST_HI_IDX 3
+
+#define EVRE_ERRINFO_BIT_POS 24
+#define EVRE_CODE_BIT_POS 28
+
+#define EVRE_ERRINFO_MASK GENMASK(3, 0)
+#define EVRE_CODE_MASK GENMASK(3, 0)
+
+#define CH_CONTROL_MASKGENMASK(7, 0)
+#define CH_STATE_MASK GENMASK(7, 0)
+#define CH_STATE_BIT_POS 0x8
+
+#define IRQ_EV_CH_EOB_IRQ_BIT_POS 0
+#define IRQ_EV_CH_WR_RESP_BIT_POS 1
+#define IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS 9
+#define IRQ_TR_CH_DATA_RD_ER_BIT_POS 10
+#define IRQ_TR_CH_DATA_WR_ER_BIT_POS 11
+#define IRQ_TR_CH_INVALID_TRE_BIT_POS 14
+
+#defineENABLE_IRQS (BIT(IRQ_EV_CH_EOB_IRQ_BIT_POS) | \
+ BIT(IRQ_EV_CH_WR_RESP_BIT_POS) | \
+ BIT(IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS)| \
+ BIT(IRQ_TR_CH_DATA_RD_ER_BIT_POS) | \
[PATCH V10 3/7] dma: add Qualcomm Technologies HIDMA management driver
The Qualcomm Technologies HIDMA device has been designed to support virtualization technology. The driver has been divided into two to follow the hardware design. 1. HIDMA Management driver 2. HIDMA Channel driver Each HIDMA HW consists of multiple channels. These channels share some set of common parameters. These parameters are initialized by the management driver during power up. Same management driver is used for monitoring the execution of the channels. Management driver can change the performance behavior dynamically such as bandwidth allocation and prioritization. The management driver is executed in hypervisor context and is the main management entity for all channels provided by the device. Signed-off-by: Sinan Kaya Reviewed-by: Andy Shevchenko --- .../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++ drivers/dma/qcom/Kconfig | 11 + drivers/dma/qcom/Makefile | 2 + drivers/dma/qcom/hidma_mgmt.c | 302 + drivers/dma/qcom/hidma_mgmt.h | 39 +++ drivers/dma/qcom/hidma_mgmt_sys.c | 295 6 files changed, 746 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt create mode 100644 drivers/dma/qcom/hidma_mgmt.c create mode 100644 drivers/dma/qcom/hidma_mgmt.h create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt new file mode 100644 index 000..c2fb5d0 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt @@ -0,0 +1,97 @@ +What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority + /sys/devices/platform/QCOM8060:*/chanops/chan*/priority +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya " +Description: + Contains either 0 or 1 and indicates if the DMA channel is a + low priority (0) or high priority (1) channel. + +What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/weight + /sys/devices/platform/QCOM8060:*/chanops/chan*/weight +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya " +Description: + Contains 0..15 and indicates the weight of the channel among + equal priority channels during round robin scheduling. + +What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles + /sys/devices/platform/QCOM8060:*/chreset_timeout_cycles +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya " +Description: + Contains the platform specific cycle value to wait after a + reset command is issued. If the value is chosen too short, + then the HW will issue a reset failure interrupt. The value + is platform specific and should not be changed without + consultance. + +What: /sys/devices/platform/hidma-mgmt*/dma_channels + /sys/devices/platform/QCOM8060:*/dma_channels +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya " +Description: + Contains the number of dma channels supported by one instance + of HIDMA hardware. The value may change from chip to chip. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_major + /sys/devices/platform/QCOM8060:*/hw_version_major +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya " +Description: + Version number major for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_minor + /sys/devices/platform/QCOM8060:*/hw_version_minor +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya " +Description: + Version number minor for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions + /sys/devices/platform/QCOM8060:*/max_rd_xactions +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya " +Description: + Contains a value between 0 and 31. Maximum number of + read transactions that can be issued back to back. + Choosing a higher number gives better performance but + can also cause performance reduction to other peripherals + sharing the same bus. + +What: /sys/devices/platform/hidma-mgmt*/max_read_request + /sys/devices/platform/QCOM8060:*/max_read_request +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya " +Description: + Size of each read request. The value needs to be a power + of two and can be between 128 and 1024. + +What: /sys/devices/platform/hidma-mgmt*/max_wr_xactions + /sys/devices/platform/QCOM8060:*/max_wr_xactions +Date: Nov 2015 +KernelV
[PATCH V10 2/7] dma: hidma: Add Device Tree support
Add documentation for the Qualcomm Technologies HIDMA driver.
Signed-off-by: Sinan Kaya
---
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 79 ++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
new file mode 100644
index 000..0e6ed1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -0,0 +1,79 @@
+Qualcomm Technologies HIDMA Management interface
+
+Qualcomm Technologies HIDMA is a high speed DMA device. It only supports
+memcpy and memset capabilities. It has been designed for virtualized
+environments.
+
+Each HIDMA HW instance consists of multiple DMA channels. These channels
+share the same bandwidth. The bandwidth utilization can be parititioned
+among channels based on the priority and weight assignments.
+
+There are only two priority levels and 15 weigh assignments possible.
+
+Other parameters here determine how much of the system bus this HIDMA
+instance can use like maximum read/write request and and number of bytes to
+read/write in a single burst.
+
+Main node required properties:
+- compatible: "qcom,hidma-mgmt-1.0";
+- reg: Address range for DMA device
+- dma-channels: Number of channels supported by this DMA controller.
+- max-write-burst-bytes: Maximum write burst in bytes. A memcpy requested is
+ fragmented to multiples of this amount.
+- max-read-burst-bytes: Maximum read burst in bytes. A memcpy request is
+ fragmented to multiples of this amount.
+- max-write-transactions: Maximum write transactions to perform in a burst
+- max-read-transactions: Maximum read transactions to perform in a burst
+- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
+
+Sub-nodes:
+
+HIDMA has one or more DMA channels that are used to move data from one
+memory location to another.
+
+Each DMA channel is described as a sub-node under the management object.
+When a transfer channel is given to the guest operating system, only the
channel
+object is created. The drivers have support for both flat and hierarchical
+configuration.
+
+Required properties:
+- compatible: must contain "qcom,hidma-1.0"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- channel-index: The HW event channel completions will be delivered.
+
+Example:
+
+Hypervisor OS configuration:
+
+ hidma-mgmt@f9984000 = {
+ compatible = "qcom,hidma-mgmt-1.0";
+ reg = <0xf9984000 0x15000>;
+ dma-channels = <6>;
+ max-write-burst-bytes = <1024>;
+ max-read-burst-bytes = <1024>;
+ max-write-transactions = <31>;
+ max-read-transactions = <31>;
+ channel-reset-timeout-cycles = <0x500>;
+
+ hidma_24: dma-controller@0x5c05 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ channel-index = <4>;
+ };
+ };
+
+Guest OS configuration:
+
+ hidma_24: dma-controller@0x5c05 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ channel-index = <4>;
+ };
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V10 6/7] dma: qcom_hidma: add debugfs hooks
Add debugfs hooks for debugging the execution behavior of the DMA
channel. The debugfs hooks get initialized by the probe function and
uninitialized by the remove function.
A stats file is created in debugfs. The stats file will show the
information about each HIDMA channel as well as each asynchronous job
queued and completed at a given time.
Signed-off-by: Sinan Kaya
---
drivers/dma/qcom/Makefile| 2 +-
drivers/dma/qcom/hidma.c | 3 +
drivers/dma/qcom/hidma.h | 2 +
drivers/dma/qcom/hidma_dbg.c | 219 +++
4 files changed, 225 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/qcom/hidma_dbg.c
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 6bf9267..4bfc38b 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -2,4 +2,4 @@ obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
hdma_mgmt-objs := hidma_mgmt.o hidma_mgmt_sys.o
obj-$(CONFIG_QCOM_HIDMA) += hdma.o
-hdma-objs:= hidma_ll.o hidma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index f8960f1..833db9e 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -681,6 +681,7 @@ static int hidma_probe(struct platform_device *pdev)
dmadev->irq = chirq;
tasklet_init(&dmadev->task, hidma_issue_task, (unsigned long)dmadev);
+ hidma_debug_init(dmadev);
dev_info(&pdev->dev, "HI-DMA engine driver registration complete\n");
platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -689,6 +690,7 @@ static int hidma_probe(struct platform_device *pdev)
return 0;
uninit:
+ hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
dmafree:
if (dmadev)
@@ -706,6 +708,7 @@ static int hidma_remove(struct platform_device *pdev)
pm_runtime_get_sync(dmadev->ddev.dev);
dma_async_device_unregister(&dmadev->ddev);
devm_free_irq(dmadev->ddev.dev, dmadev->irq, dmadev->lldev);
+ hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
hidma_free(dmadev);
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index 1e09d7c..c6b3ae0 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -157,4 +157,6 @@ int hidma_ll_uninit(struct hidma_lldev *llhndl);
irqreturn_t hidma_ll_inthandler(int irq, void *arg);
void hidma_cleanup_pending_tre(struct hidma_lldev *llhndl, u8 err_info,
u8 err_code);
+int hidma_debug_init(struct hidma_dev *dmadev);
+void hidma_debug_uninit(struct hidma_dev *dmadev);
#endif
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
new file mode 100644
index 000..fe35002
--- /dev/null
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -0,0 +1,219 @@
+/*
+ * Qualcomm Technologies HIDMA debug file
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "hidma.h"
+
+static void hidma_ll_chstats(struct seq_file *s, void *llhndl, u32 tre_ch)
+{
+ struct hidma_lldev *lldev = llhndl;
+ struct hidma_tre *tre;
+ u32 length;
+ dma_addr_t src_start;
+ dma_addr_t dest_start;
+ u32 *tre_local;
+
+ if (tre_ch >= lldev->nr_tres) {
+ dev_err(lldev->dev, "invalid TRE number in chstats:%d", tre_ch);
+ return;
+ }
+ tre = &lldev->trepool[tre_ch];
+ seq_printf(s, "--Channel %d -\n", tre_ch);
+ seq_printf(s, "allocated=%d\n", atomic_read(&tre->allocated));
+ seq_printf(s, "queued = 0x%x\n", tre->queued);
+ seq_printf(s, "err_info = 0x%x\n",
+ lldev->tx_status_list[tre->idx].err_info);
+ seq_printf(s, "err_code = 0x%x\n",
+ lldev->tx_status_list[tre->idx].err_code);
+ seq_printf(s, "status = 0x%x\n", tre->status);
+ seq_printf(s, "idx = 0x%x\n", tre->idx);
+ seq_printf(s, "dma_sig = 0x%x\n", tre->dma_sig);
+ seq_printf(s, "dev_name=%s\n", tre->dev_name);
+ seq_printf(s, "callback=%p\n", tre->callback);
+ seq_printf(s, "data=%p\n", tre->data);
+ seq_printf(s, "tre_index = 0x%x\n", tre->tre_index);
+
+ tre_local = &tre->tre_local[0];
+ src_start = tre_local[TRE_SRC_LOW_IDX];
+ src_start = ((u64) (tre_local[TRE_SRC_HI_IDX]) << 32) + src_start;
+ dest_start = tre_local[T
[PATCH V10 4/7] dma: add Qualcomm Technologies HIDMA channel driver
This patch adds support for hidma engine. The driver consists of two
logical blocks. The DMA engine interface and the low-level interface.
The hardware only supports memcpy/memset and this driver only support
memcpy interface. HW and driver doesn't support slave interface.
Signed-off-by: Sinan Kaya
---
drivers/dma/qcom/Kconfig | 10 +
drivers/dma/qcom/hidma.c | 744 +++
drivers/dma/qcom/hidma.h | 160 ++
3 files changed, 914 insertions(+)
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index ebe5b8c..5588e1c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -17,3 +17,13 @@ config QCOM_HIDMA_MGMT
start managing the channels. In a virtualized environment,
the guest OS would run QCOM_HIDMA channel driver and the
hypervisor would run the QCOM_HIDMA_MGMT management driver.
+
+config QCOM_HIDMA
+ tristate "Qualcomm Technologies HIDMA Channel support"
+ select DMA_ENGINE
+ help
+ Enable support for the Qualcomm Technologies HIDMA controller.
+ The HIDMA controller supports optimized buffer copies
+ (user to kernel, kernel to kernel, etc.). It only supports
+ memcpy interface. The core is not intended for general
+ purpose slave DMA.
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
new file mode 100644
index 000..f8960f1
--- /dev/null
+++ b/drivers/dma/qcom/hidma.c
@@ -0,0 +1,744 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik . Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen .
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009; for details see www.osadl.org.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * The full GNU General Public License is included in this distribution in the
+ * file called COPYING.
+ */
+
+/* Linux Foundation elects GPLv2 license only. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../dmaengine.h"
+#include "hidma.h"
+
+/*
+ * Default idle time is 2 seconds. This parameter can
+ * be overridden by changing the following
+ * /sys/bus/platform/devices/QCOM8061:/power/autosuspend_delay_ms
+ * during kernel boot.
+ */
+#define HIDMA_AUTOSUSPEND_TIMEOUT 2000
+#define HIDMA_ERR_INFO_SW 0xFF
+#define HIDMA_ERR_CODE_UNEXPECTED_TERMINATE0x0
+
+static inline struct hidma_dev *to_hidma_dev(struct dma_device *dmadev)
+{
+ return container_of(dmadev, struct hidma_dev, ddev);
+}
+
+static inline
+struct hidma_dev *to_hidma_dev_from_lldev(struct hidma_lldev **_lldevp)
+{
+ return container_of(_lldevp, struct hidma_dev, lldev);
+}
+
+static inline struct hidma_chan *to_hidma_chan(struct dma_chan *dmach)
+{
+ return container_of(dmach, struct hidma_chan, chan);
+}
+
+static inline
+struct hidma_desc *to_hidma_desc(struct dma_async_tx_descriptor *t)
+{
+ return container_of(t, struct hidma_desc, desc);
+}
+
+static void hidma_free(struct hidma_dev *dmadev)
+{
+ INIT_LIST_HEAD(&dmadev->ddev.channels);
+}
+
+static unsigned int nr_desc_prm;
+module_param(nr_desc_prm, uint, 0644);
+MODULE_PARM_DESC(nr_desc_prm, "number of descriptors (default: 0)");
+
+#define HIDMA_MAX_CHANNELS 64
+static int channel_idx[HIDMA_MAX_CHANNELS] = {
+ [0 ... (HIDMA_MAX_CHANNELS - 1)] = -1
+};
+
+/*
+ * Each DMA channel is associated with an event channel for interrupt
+
[PATCH V10 7/7] dma: qcom_hidma: add support for object hierarchy
In order to create a relationship model between the channels and the
management object, we are adding support for object hierarchy to the
drivers. This patch simplifies the userspace application development.
We will not have to traverse different firmware paths based on device
tree or ACPI baed kernels.
No matter what flavor of kernel is used, objects will be represented as
platform devices.
The new layout is as follows:
hidmam_10: hidma-mgmt@0x5A00 {
compatible = "qcom,hidma-mgmt-1.0";
...
hidma_10: hidma@0x5a01 {
compatible = "qcom,hidma-1.0";
...
}
}
The hidma_mgmt_init detects each instance of the hidma-mgmt-1.0 objects
in device tree and calls into the channel driver to create platform devices
for each child of the management object.
Signed-off-by: Sinan Kaya
---
Documentation/ABI/testing/sysfs-platform-hidma | 9 +++
drivers/dma/qcom/hidma.c | 39 +-
drivers/dma/qcom/hidma_mgmt.c | 103 -
3 files changed, 147 insertions(+), 4 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma
diff --git a/Documentation/ABI/testing/sysfs-platform-hidma
b/Documentation/ABI/testing/sysfs-platform-hidma
new file mode 100644
index 000..d364415
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-hidma
@@ -0,0 +1,9 @@
+What: /sys/devices/platform/hidma-*/chid
+ /sys/devices/platform/QCOM8061:*/chid
+Date: Dec 2015
+KernelVersion: 4.4
+Contact: "Sinan Kaya "
+Description:
+ Contains the ID of the channel within the HIDMA instance.
+ It is used to associate a given HIDMA channel with the
+ priority and weight calls in the management interface.
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 833db9e..ac20bdb 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -549,6 +549,43 @@ static irqreturn_t hidma_chirq_handler(int chirq, void
*arg)
return hidma_ll_inthandler(chirq, lldev);
}
+static ssize_t hidma_show_values(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct hidma_dev *mdev = platform_get_drvdata(pdev);
+
+ buf[0] = 0;
+
+ if (strcmp(attr->attr.name, "chid") == 0)
+ sprintf(buf, "%d\n", mdev->chidx);
+
+ return strlen(buf);
+}
+
+static int hidma_create_sysfs_entry(struct hidma_dev *dev, char *name,
+ int mode)
+{
+ struct device_attribute *attrs;
+ char *name_copy;
+
+ attrs = devm_kmalloc(dev->ddev.dev, sizeof(struct device_attribute),
+GFP_KERNEL);
+ if (!attrs)
+ return -ENOMEM;
+
+ name_copy = devm_kstrdup(dev->ddev.dev, name, GFP_KERNEL);
+ if (!name_copy)
+ return -ENOMEM;
+
+ attrs->attr.name = name_copy;
+ attrs->attr.mode = mode;
+ attrs->show = hidma_show_values;
+ sysfs_attr_init(&attrs->attr);
+
+ return device_create_file(dev->ddev.dev, attrs);
+}
+
static int hidma_probe(struct platform_device *pdev)
{
struct hidma_dev *dmadev;
@@ -682,6 +719,7 @@ static int hidma_probe(struct platform_device *pdev)
dmadev->irq = chirq;
tasklet_init(&dmadev->task, hidma_issue_task, (unsigned long)dmadev);
hidma_debug_init(dmadev);
+ hidma_create_sysfs_entry(dmadev, "chid", S_IRUGO);
dev_info(&pdev->dev, "HI-DMA engine driver registration complete\n");
platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -730,7 +768,6 @@ static const struct of_device_id hidma_match[] = {
{.compatible = "qcom,hidma-1.0",},
{},
};
-
MODULE_DEVICE_TABLE(of, hidma_match);
static struct platform_driver hidma_driver = {
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index ef491b8..d387338 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -17,13 +17,14 @@
#include
#include
#include
-#include
-#include
+#include
+#include
#include
#include
#include
#include
#include
+#include
#include "hidma_mgmt.h"
@@ -298,5 +299,101 @@ static struct platform_driver hidma_mgmt_driver = {
},
};
-module_platform_driver(hidma_mgmt_driver);
+#ifdef CONFIG_OF
+static int object_counter;
+
+static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
+{
+ struct platform_device *pdev_parent = of_find_device_by_node(np);
+ struct platform_device_info pdevinfo;
+ struct of_phandle_args out_irq;
+ struct device_node *child;
+ struct resource *res;
+ const __be32 *cell;
+ int ret = 0, size, i, num;
+ u64 addr, addr_size;
+
+ for_each_available_child_
[PATCH V10 0/7] dma: add Qualcomm Technologies HIDMA driver
The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design.
1. HIDMA Management driver
2. HIDMA Channel driver
Each HIDMA HW consists of multiple channels. These channels
share some set of common parameters. These parameters are
initialized by the management driver during power up.
Same management driver is used for monitoring the execution
of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and
prioritization in the future.
The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.
Changes from V9: (https://lkml.org/lkml/2015/12/11/584)
* none
Changes from V9: (https://lkml.org/lkml/2015/12/11/585)
* split device tree documentation from code
* correct syntax error in device tree documentation
* describe max value of the weight
* document that array and weight attributes are array
* add object hierarchy support
* move sysfs priority and weight files into chanops directory.
Changes from V9: (https://lkml.org/lkml/2015/12/11/588)
* add object hierarchy support
* rename event-channel to channel-index
* create a sysfs entry for channel-index
* add pm_runtime_get/sync around hidma_ll_isenabled
Changes from V9: (https://lkml.org/lkml/2015/12/11/586)
* rename TRE chidx to idx to not mix with the channel id.
Changes from V9: (https://lkml.org/lkml/2015/12/11/587)
* none
Sinan Kaya (7):
dma: qcom_bam_dma: move to qcom directory
dma: hidma: Add Device Tree support
dma: add Qualcomm Technologies HIDMA management driver
dma: add Qualcomm Technologies HIDMA channel driver
dma: qcom_hidma: implement lower level hardware interface
dma: qcom_hidma: add debugfs hooks
dma: qcom_hidma: add support for object hierarchy
Documentation/ABI/testing/sysfs-platform-hidma | 9 +
.../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 79 ++
drivers/dma/Kconfig| 11 +-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 29 +
drivers/dma/qcom/Makefile | 4 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 +-
drivers/dma/qcom/hidma.c | 868 +++
drivers/dma/qcom/hidma.h | 163
drivers/dma/qcom/hidma_dbg.c | 219 +
drivers/dma/qcom/hidma_ll.c| 927 +
drivers/dma/qcom/hidma_mgmt.c | 317 +++
drivers/dma/qcom/hidma_mgmt.h | 39 +
drivers/dma/qcom/hidma_mgmt_sys.c | 295 +++
15 files changed, 3051 insertions(+), 12 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma
create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
create mode 100644 drivers/dma/qcom/hidma_dbg.c
create mode 100644 drivers/dma/qcom/hidma_ll.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.h
create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/26] devicetree: bindings: Document qcom,msm-id and qcom,board-id
From: Kumar Gala The top level qcom,msm-id and qcom,board-id are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be utilized and passed to the kernel. Cc: Signed-off-by: Kumar Gala --- Documentation/devicetree/bindings/arm/msm/ids.txt | 65 +++ include/dt-bindings/arm/qcom-ids.h| 33 2 files changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/msm/ids.txt create mode 100644 include/dt-bindings/arm/qcom-ids.h diff --git a/Documentation/devicetree/bindings/arm/msm/ids.txt b/Documentation/devicetree/bindings/arm/msm/ids.txt new file mode 100644 index 000..9ee8428 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/ids.txt @@ -0,0 +1,65 @@ +* MSM-ID + +The qcom,msm-id entry specifies the MSM chipset and hardware revision. It can +optionally be an array of these to indicate multiple hardware that use the same +device tree. It is expected that the bootloader will use this information at +boot-up to decide which device tree to use when given multiple device trees, +some of which may not be compatible with the actual hardware. It is the +bootloader's responsibility to pass the correct device tree to the kernel. + +PROPERTIES + +- qcom,msm-id: + Usage: required + Value type: ( [, ..]) + Definition: + The "chipset_id" consists of three fields as below: + + bits 0-15 = The unique MSM chipset id. + bits 16-31 = Reserved. Should be 0 + + chipset_id is an exact match value + + The "rev_id" is a chipset specific 32-bit id that represents + the version of the chipset. + + The rev_id is a best match id. The bootloader will look for + the closest possible patch. + +* BOARD-ID + +The qcom,board-id entry specifies the board type and revision information. It +can optionally be an array of these to indicate multiple boards that use the +same device tree. It is expected that the bootloader will use this information +at boot-up to decide which device tree to use when given multiple device trees, +some of which may not be compatible with the actual hardware. It is the +bootloader's responsibility to pass the correct device tree to the kernel. + +PROPERTIES + +- qcom,board-id: + Usage: required + Value type: ( [, ..]) + Definition: + The "board_id" consists of three fields as below: + + bits 31-24 = Unusued. + bits 23-16 = Platform Version Major + bits 15-8 = Platfrom Version Minor + bits 7-0 = Platform Type + + Platform Type field is an exact match value. The Platform + Major/Minor field is a best match. The bootloader will look + for the closest possible match. + + The "subtype_id" is unique to a Platform Type/Chipset ID. For + a given Platform Type, there will typically only be a single + board and the subtype_id will be 0. However in some cases board + variants may need to be distinquished by different subtype_id + values. + + subtype_id is an exact match value. + +EXAMPLE: + qcom,board-id = <15 2>; + qcom,msm-id = <0x1007e 0>; diff --git a/include/dt-bindings/arm/qcom-ids.h b/include/dt-bindings/arm/qcom-ids.h new file mode 100644 index 000..a18f34e --- /dev/null +++ b/include/dt-bindings/arm/qcom-ids.h @@ -0,0 +1,33 @@ +/* Copyright (c) 2015, The Linux Foundation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#ifndef __DT_BINDINGS_QCOM_IDS_H +#define __DT_BINDINGS_QCOM_IDS_H + +/* qcom,msm-id */ +#define QCOM_ID_MSM8916206 +#define QCOM_ID_APQ8016247 +#define QCOM_ID_MSM8216248 +#define QCOM_ID_MSM8116249 +#define QCOM_ID_MSM8616250 + +/* qcom,board-id */ +#define QCOM_BRD_ID(a, major, minor) \ + (((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BRD_ID_##a) + +#define QCOM_BRD_ID_MTP8 +#define QCOM_BRD_ID_DRAGONBRD 10 +#define QCOM_BRD_ID_SBC24 + +#define QCOM_BRD_SUBTYPE_DEFAULT 0 +#define QCOM_BRD_SUBTYPE_MTP8916_SMB1360 1 + +#endif -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info
Re: [PATCH v3] net/macb: add support for resetting PHY using GPIO
From: Gregory CLEMENT Date: Thu, 17 Dec 2015 09:39:32 +0100 > if I remebered well you do not remove patch from yout branch. So would > you agree to take a follow-up patch on top of 5833e0526820 "net/macb: > add support for resetting PHY using GPIO" ? Yes. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] Raspberry Pi power domains
On 15 December 2015 at 22:40, Eric Anholt wrote: > Since the pm_genpd_exit() patch is still going through review, and > other drivers in the tree just ignore the error cases, Ulf offered to > merge the series as a builtin driver not depending on that interface. > We still avoid dangling pointer references, by just continuing with > probing if of_genpd_add_provider_onecell() fails. We can easily go > back and update the driver when a pm_genpd_exit() lands. > > Alexander Aring (3): > ARM: bcm2835: add rpi power domain driver > dt-bindings: add rpi power domain driver bindings > ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. > > Eric Anholt (1): > ARM: bcm2835: Define two new packets from the latest firmware. > > .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt | 47 > arch/arm/boot/dts/bcm2835-rpi.dtsi | 11 + > arch/arm/boot/dts/bcm2835.dtsi | 2 +- > arch/arm/mach-bcm/Kconfig | 10 + > arch/arm/mach-bcm/Makefile | 1 + > arch/arm/mach-bcm/raspberrypi-power.c | 247 > + > include/dt-bindings/arm/raspberrypi-power.h| 41 > include/soc/bcm2835/raspberrypi-firmware.h | 2 + > 8 files changed, 360 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt > create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c > create mode 100644 include/dt-bindings/arm/raspberrypi-power.h > > -- > 2.6.2 > Besides a nitpick for patch2, I would also reverse the order of patch3 and patch2. DT docs should go in before the actual parsing of the new bindings/compatibles. Anyway, for the hole series, you may add my: Reviewed-by: Ulf Hansson Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/4] ARM: bcm2835: add rpi power domain driver
On 17 December 2015 at 01:26, Eric Anholt wrote: > From: Alexander Aring > > This patch adds support for several power domains on Raspberry Pi, > including USB (so it can be enabled even if the bootloader didn't do > it), and graphics. > > This patch is the combined work of Eric Anholt (who wrote USB support > inside of the Raspberry Pi firmware driver, and wrote the non-USB > domain support) and Alexander Aring (who separated the original USB > work out from the firmware driver). > > Signed-off-by: Alexander Aring > Signed-off-by: Eric Anholt > --- > > v2: Add support for power domains other than USB, using the new > firmware interface, reword commit message (changes by Eric) > > v3: Restructure as a builtin driver, and drop > of_genpd_add_provider_onecell error handling to avoid > pm_genpd_exit() dependency until that API can be settled. Clean > up copyright header, add missing ISP initialization, and fix typo > in transposer's name. > > v4: Move to drivers/soc/bcm/, move include to dt-bindings/soc/, set up > Makefile for the drivers/soc/bcm following clk/'s model. > > drivers/soc/Kconfig | 1 + > drivers/soc/Makefile| 1 + > drivers/soc/bcm/Kconfig | 9 + > drivers/soc/bcm/Makefile| 1 + > drivers/soc/bcm/raspberrypi-power.c | 247 > > include/dt-bindings/soc/raspberrypi-power.h | 41 + There is currently a directory which I think may be better. include/dt-bindings/power/* Besides this nitpick, I think this looks good. You may add my: Reviewed-by: Ulf Hansson Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
On Wed, 16 Dec 2015, Rob Herring wrote: > On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote: > > On Monday 14 December 2015 15:26:11 Peter Chen wrote: > >> Hi all, > >> > >> There is a known issue that the USB code can't handle USB HUB's > >> external pins well, in that case, it may cause some onboard > >> USB HUBs can't work since their PHY's clock or reset pin needs to > >> operate. > >> > >> The user reported this issue at below: > >> http://www.spinics.net/lists/linux-usb/msg131502.html > >> > >> In this patch set, I add a generic onboard USB HUB driver to > >> handle this problem, the external signals will be configured > >> before usb controller's initialization, it much likes we did > >> it at board code before. > >> > >> The user needs to add this generic hub node at dts to support it. > >> > >> @The udoo users, help to test please. > > > > I still think need to do this properly by representing the hub > > device as a USB device, using power sequencing code like MMC does. > > I agree on doing it properly, but am not sure that pwrseq binding for > MMC is proper. The pwrseq binding is fairly limited and working around > the driver model IMO. Hubs may also need I2C setup which I don't think > could be done generically other than some defined sequence of i2c > transactions. The current project I'm working on needs to use I2C to > configure the hub to use HSIC mode for example. I really think we need > a pre-probe driver hook to handle this. That would allow device > specific setup to live in the driver. > > Perhaps a more simple approach would be just forcing driver probe if a > DT node is present. I'm not all that familiar with USB drivers, but > presumably there is some setup before probe like setting the USB > device address. We'd have to allow doing that later during probe. It's not clear (to me, anyway) how this is meant to work. USB is a completely discoverable bus: There is no way to represent devices statically; they have to be discovered. But a device can't be discovered unless it is functional, so if an onboard hub (or any other sort of USB device) requires power, clocks, or something similar in order to function, it won't be discovered. There won't be any device structure to probe, and "forcing driver probe" won't accomplish anything. It seems to me that the only way something like this could be made to work is if the necessary actions are keyed off the host controller (and in particular, _not_ the hub driver), presumably at the time the controller is probed. With anything else, you run the risk that the necessary resources won't get enabled before they are needed. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/4] SysFS driver for QEMU fw_cfg device
ping ?
Also, for the corresponding patch set on the QEMU end of things,
ping on http://thread.gmane.org/gmane.comp.emulators.qemu/376321
Thanks,
--Gabriel
On Fri, Dec 04, 2015 at 10:29:02AM -0500, Gabriel L. Somlo wrote:
> Allow access to QEMU firmware blobs, passed into the guest VM via
> the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
> size, and fw_cfg key), as well as the raw binary blob data may be
> accessed.
>
> The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was
> selected based on overall similarity to the type of information
> exposed under /sys/firmware/dmi/entries/...
>
> New since v5:
>
> - fixed typos in documentation files (Patches 1/4 and 4/4
>
> - printf/scanf type modifier for phys_addr_t now matches
> arch-specific width (u32 vs. u64), avoiding compiler warnings.
> (tested on i386 with and without PAE, and on armv7hl with and
> without lpae -- the latter pair took quite a while on an
> emulated QEMU guest :) )
>
> Thanks,
> --Gabriel
>
> >New since v4:
> >
> > Documentation (Patches 1/4 and 4/4) now points to the authoritative
> > file in the QEMU source tree for any details related to the "hardware
> > interface" of the fw_cfg device; Only details specific to sysfs (1/4)
> > and DT (4/4) should stay in the kernel docs.
> >
> >>New (since v3):
> >>
> >>Patch 1/4: Device probing now works with either ACPI, DT, or
> >> optionally by manually specifying a base, size, and
> >> register offsets on the command line. This way, all
> >> architectures offering fw_cfg can be supported, although
> >> x86 and ARM get *automatic* support via ACPI and/or DT.
> >>
> >> HUGE thanks to Laszlo Ersek for
> >> pointing out drivers/virtio/virtio_mmio.c, as an example
> >> on how to pull this off !!!
> >>
> >> Stefan: I saw Marc's DMA patches to fw_cfg. Since only
> >> x86 and ARM will support it starting with QEMU 2.5, and
> >> since I expect to get lots of otherwise interesting (but
> >> otherwise orthogonal) feedback on this series, I'd like
> >> to stick with ioread8() across the board for now. We can
> >> always patch in DMA support in a backward compatible way
> >> later, once this series gets (hopefully) accepted :)
> >>
> >>Patch 2/4: (was 3/4 in v3): unchanged. Exports kset_find_obj() so
> >> modules can call it.
> >>
> >>Patch 3/4: (was 4/4 in v3): rebased, but otherwise the same.
> >> Essentially, creates a "human readable" directory
> >> hierarchy from "path-like" tokens making up fw_cfg
> >> blob names. I'm not really sure there's a way to make
> >> this happen via udev rules, but I have at least one
> >> potential use case for doing it *before* udev becomes
> >> available (cc: Andy Lutomirski ),
> >> so I'd be happy to leave this functionality in the
> >> kernel module. See further below for an illustration
> >> of this.
> >>
> >>Patch 4/4: Updates the existing ARM DT documentation for fw_cfg,
> >> mainly by pointing at the more comprehensive document
> >> introduced with Patch 1/4 for details on the fw_cfg
> >> device interface, leaving only the specific ARM/DT
> >> address/size node information in place.
> >>
> >>> In addition to the "by_key" blob listing, e.g.:
> >>>
> >>> $ tree /sys/firmware/qemu_fw_cfg/
> >>> /sys/firmware/qemu_fw_cfg/
> >>> |-- by_key
> >>> | |-- 32
> >>> | | |-- key
> >>> | | |-- name("etc/boot-fail-wait")
> >>> | | |-- raw
> >>> | | `-- size
> >>> | |-- 33
> >>> | | |-- key
> >>> | | |-- name("etc/smbios/smbios-tables")
> >>> | | |-- raw
> >>> | | `-- size
> >>> | |-- 34
> >>> | | |-- key
> >>> | | |-- name("etc/smbios/smbios-anchor")
> >>> | | |-- raw
> >>> | | `-- size
> >>> | |-- 35
> >>> | | |-- key
> >>> | | |-- name("etc/e820")
> >>> | | |-- raw
> >>> | | `-- size
> >>> | |-- 36
> >>> | | |-- key
> >>> | | |-- name("genroms/kvmvapic.bin")
> >>> | | |-- raw
> >>> | | `-- size
> >>> | |-- 37
> >>> | | |-- key
> >>> | | |-- name("etc/system-states")
> >>> | | |-- raw
> >>> | | `-- size
> >>> | |-- 38
> >>> | | |-- key
> >>> | | |-- name("etc/acpi/tables")
> >>> | | |-- raw
> >>> | | `-- size
> >>> | |-- 39
> >>> | | |-- key
> >>> | | |-- name("etc/table-loader")
> >>> | | |-- raw
> >>> |
Re: [PATCH v4 1/5] PCI: designware: add memory barrier after enabling region
On Thu, Dec 17, 2015 at 9:15 PM, Stanimir Varbanov wrote: > > On 12/11/2015 06:05 AM, Pratyush Anand wrote: > > On Wed, Dec 9, 2015 at 3:53 PM, Russell King - ARM Linux > > wrote: > > > > [...] > > > > dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2); > > + /* > > + * ensure that the ATU enable has been happaned before accessing > > + * pci configuration/io spaces through dw_pcie_cfg_[read|write]. > > + */ > > + wmb(); > > } > > > >>> > >>> > >>> My understnading is that since writel() of dw_pcie_writel_rc() in > >>> above code and readl(), writel() of dw_pcie_cfg_[read|write]() (which > >>> will follow) goes through same device (ie PCIe host here). So, it is > >>> guaranteed that 1st writel() will be executed before later > >>> readl()/writel(). If that is true then we do not need any explicit > >>> barrier here. > >>> > >>> Arnd, Russel: whats your opinion here. > >> ^l > > > > Sorry :( > > > >> > >> writel() has a barrier _before_ the access but not after. > >> > >> The fact is that there's nothing which guarantees that the write will hit > >> the hardware in a timely manner (forget any rules about PCI config space, > >> the PCI ordering rules apply to the PCI bus, not to the ARM buses.) > >> > >> If you need this write to have hit the hardware before continuing, you > >> need to read back from the same register. > > > > OK, so better to replace wmb() with read back of control register. > > Would the patch be acceptable if I replace wmb with read? For me it would be fine. ~Pratyush -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Make CPU configuration more readable for exynos542x/5800
On Fri, Dec 11, 2015 at 3:17 PM, Krzysztof Kozlowski
wrote:
> Exynos5420 and Exynos5800 boards boot from big core (A15) but
> Exynos5420 boards choose otherwise: LITTLE core (A7) (on Exynos5422 this
> is property of the board - configurable by pulling up/down gpg2-1).
> To make user-visible CPU ordering more consistent the 'cpus' node was
> overridden by exynos5422-cpus.dtsi.
>
> However this is a little bit ugly and error-prone. Overriding the CPU
> child nodes requires to basically reverse what was done initially in
> exynos5420.dtsi.
>
> Instead, split CPU configuration entirely to separate files which should
> be included by board DTS.
>
> Suggested-by: Viresh Kumar
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Tested on Exynos5422 based Odroid XU4. Please kindly test on Exynos5420
> or Exynos5800 boards.
> ---
> arch/arm/boot/dts/exynos5420-arndale-octa.dts | 1 +
> arch/arm/boot/dts/exynos5420-cpus.dtsi| 92 ++
> arch/arm/boot/dts/exynos5420-peach-pit.dts| 1 +
> arch/arm/boot/dts/exynos5420-smdk5420.dts | 1 +
> arch/arm/boot/dts/exynos5420.dtsi | 72 +-
> arch/arm/boot/dts/exynos5422-cpus.dtsi| 130
> ++
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 +
> 7 files changed, 170 insertions(+), 128 deletions(-)
> create mode 100644 arch/arm/boot/dts/exynos5420-cpus.dtsi
>
> diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> index 4ecef6981d5c..365eec6f6687 100644
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -11,6 +11,7 @@
>
> /dts-v1/;
> #include "exynos5420.dtsi"
> +#include "exynos5420-cpus.dtsi"
> #include
> #include
> #include
> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi
> b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> new file mode 100644
> index ..7aaf0313274f
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> @@ -0,0 +1,92 @@
> +/*
> + * SAMSUNG EXYNOS5420 SoC cpu device tree source
> + *
> + * Copyright (c) 2015 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * This file provides desired ordering for Exynos5420 and Exynos5800
> + * boards: CPU[0123] being the A15.
> + *
> + * The Exynos5420, 5422 and 5800 actually share the same CPU configuration
> + * but particular boards choose different booting order.
> + *
> + * Exynos5420 and Exynos5800 always boot from Cortex-A15. On Exynos5422
> + * booting cluster (big or LITTLE) is chosen by IROM code by reading
> + * the gpg2-1 GPIO. By default all Exynos5422 based boards choose booting
> + * from the LITTLE: Cortex-A7.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/ {
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x0>;
> + clock-frequency = <18>;
> + cci-control-port = <&cci_control1>;
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x1>;
> + clock-frequency = <18>;
> + cci-control-port = <&cci_control1>;
> + };
> +
> + cpu2: cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x2>;
> + clock-frequency = <18>;
> + cci-control-port = <&cci_control1>;
> + };
> +
> + cpu3: cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a15";
> + reg = <0x3>;
> + clock-frequency = <18>;
> + cci-control-port = <&cci_control1>;
> + };
> +
> + cpu4: cpu@100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x100>;
> + clock-frequency = <10>;
> + cci-control-port = <&cci_control0>;
> + };
> +
> + cpu5: cpu@101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0x101>;
> + clock-frequency = <10>;
> + cci-control-port = <&cci_control0>;
> + };
> +
> + cpu6
Re: [PATCH v4 1/5] PCI: designware: add memory barrier after enabling region
On 12/11/2015 06:05 AM, Pratyush Anand wrote: > On Wed, Dec 9, 2015 at 3:53 PM, Russell King - ARM Linux > wrote: > > [...] > > dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2); > + /* > + * ensure that the ATU enable has been happaned before accessing > + * pci configuration/io spaces through dw_pcie_cfg_[read|write]. > + */ > + wmb(); > } > >>> >>> >>> My understnading is that since writel() of dw_pcie_writel_rc() in >>> above code and readl(), writel() of dw_pcie_cfg_[read|write]() (which >>> will follow) goes through same device (ie PCIe host here). So, it is >>> guaranteed that 1st writel() will be executed before later >>> readl()/writel(). If that is true then we do not need any explicit >>> barrier here. >>> >>> Arnd, Russel: whats your opinion here. >> ^l > > Sorry :( > >> >> writel() has a barrier _before_ the access but not after. >> >> The fact is that there's nothing which guarantees that the write will hit >> the hardware in a timely manner (forget any rules about PCI config space, >> the PCI ordering rules apply to the PCI bus, not to the ARM buses.) >> >> If you need this write to have hit the hardware before continuing, you >> need to read back from the same register. > > OK, so better to replace wmb() with read back of control register. Would the patch be acceptable if I replace wmb with read? -- regards, Stan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] watchdog: imx2_wdt: add external reset support via 'ext-reset-output' dt prop
On 12/17/2015 07:02 AM, Tim Harvey wrote: On Wed, Dec 2, 2015 at 12:54 PM, Tim Harvey wrote: On Wed, Dec 2, 2015 at 11:11 AM, Akshay Bhat wrote: On 11/06/2015 05:02 PM, Guenter Roeck wrote: On Fri, Nov 06, 2015 at 11:53:42AM -0800, Tim Harvey wrote: On Thu, Nov 5, 2015 at 2:23 PM, Guenter Roeck wrote: On Thu, Nov 05, 2015 at 04:19:21PM -0500, Akshay Bhat wrote: From: Tim Harvey The IMX6 watchdog supports assertion of a signal (WDOG_B) which can be pinmux'd to an external pin. This is typically used for boards that have PMIC's in control of the IMX6 power rails. In fact, failure to use such an external reset on boards with external PMIC's can result in various hangs due to the IMX6 not being fully reset [1] as well as the board failing to reset because its PMIC has not been reset to provide adequate voltage for the CPU when coming out of reset at 800Mhz. This uses a new device-tree property 'ext-reset-output' to indicate the board has such a reset and to cause the watchdog to be configured to assert WDOG_B instead of an internal reset both on a watchdog timeout and in system_restart. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333689.html Cc: Lucas Stach Signed-off-by: Tim Harvey --- .../devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 ++ drivers/watchdog/imx2_wdt.c | 20 ++-- 2 files changed, 20 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt index 8dab6fd..9b89b3a 100644 --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt @@ -9,6 +9,8 @@ Optional property: properties ? - big-endian: If present the watchdog device's registers are implemented in big endian mode, otherwise in native mode(same with CPU), for more detail please see: Documentation/devicetree/bindings/regmap/regmap.txt. +- ext-reset-output: If present the watchdog device is configured to assert its Should that have a vendor prefix ? Also, not sure if "-output" has any real value in the property name. "fsl,external-reset", maybe ? Hi Guenter, I don't see why a vendor prefix is necessary - its a feature of the IMX6 watchdog supported by this driver to be able to trigger an internal chip-level reset and/or an external signal that can be hooked to additional hardware. Sounded like vendor specific to me, but then I am not a devicetree maintainer, so I am not an authority on the subject. Devicetree maintainers, Any thoughts? Tim, After looking at all the other watchdog drivers, it does not appear that there is any other processor which uses a similar feature. Since imx is the only processor that appears to support this feature, it might make sense in making this vendor specific. If in the future it is found more processors support a similar functionality, it can be revisited and moved out from being vendor specific? I'm certainly no expert on device-tree policy. I understand your point, but realize that the driver in question is imx2_wdt.c (compatible = "fsl,imx21-wdt"). This is an IP block inside the silicon of only Freescale chips, so its not like a future omap chip would be using this driver - only fsl devices. So why would it need a 'vendor' property any more than its other properties? Regards, Tim Wim, Does the lack of response mean overwhelming approval? I haven't heard any valid complaints - what does it take to get this approved? Tim, Do you have an Ack from a devicetree maintainer ? I don't recall seeing one. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] watchdog: imx2_wdt: add external reset support via 'ext-reset-output' dt prop
On Wed, Dec 2, 2015 at 12:54 PM, Tim Harvey wrote: > > On Wed, Dec 2, 2015 at 11:11 AM, Akshay Bhat wrote: > > > > > > On 11/06/2015 05:02 PM, Guenter Roeck wrote: > >> > >> On Fri, Nov 06, 2015 at 11:53:42AM -0800, Tim Harvey wrote: > >>> > >>> On Thu, Nov 5, 2015 at 2:23 PM, Guenter Roeck wrote: > > On Thu, Nov 05, 2015 at 04:19:21PM -0500, Akshay Bhat wrote: > > > > From: Tim Harvey > > > > The IMX6 watchdog supports assertion of a signal (WDOG_B) which > > can be pinmux'd to an external pin. This is typically used for boards > > that > > have PMIC's in control of the IMX6 power rails. In fact, failure to use > > such an external reset on boards with external PMIC's can result in > > various > > hangs due to the IMX6 not being fully reset [1] as well as the board > > failing > > to reset because its PMIC has not been reset to provide adequate > > voltage for > > the CPU when coming out of reset at 800Mhz. > > > > This uses a new device-tree property 'ext-reset-output' to indicate the > > board has such a reset and to cause the watchdog to be configured to > > assert > > WDOG_B instead of an internal reset both on a watchdog timeout and in > > system_restart. > > > > [1] > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333689.html > > > > Cc: Lucas Stach > > Signed-off-by: Tim Harvey > > --- > > .../devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 ++ > > drivers/watchdog/imx2_wdt.c | 20 > > ++-- > > 2 files changed, 20 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt > > b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt > > index 8dab6fd..9b89b3a 100644 > > --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt > > +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt > > @@ -9,6 +9,8 @@ Optional property: > > > properties ? > > > - big-endian: If present the watchdog device's registers are > > implemented > > in big endian mode, otherwise in native mode(same with CPU), for > > more > > detail please see: > > Documentation/devicetree/bindings/regmap/regmap.txt. > > +- ext-reset-output: If present the watchdog device is configured to > > assert its > > > Should that have a vendor prefix ? Also, not sure if "-output" > has any real value in the property name. "fsl,external-reset", maybe ? > >>> > >>> > >>> Hi Guenter, > >>> > >>> I don't see why a vendor prefix is necessary - its a feature of the > >>> IMX6 watchdog supported by this driver to be able to trigger an > >>> internal chip-level reset and/or an external signal that can be hooked > >>> to additional hardware. > >>> > >> Sounded like vendor specific to me, but then I am not a devicetree > >> maintainer, > >> so I am not an authority on the subject. > > > > > > Devicetree maintainers, > > > > Any thoughts? > > > > Tim, > > > > After looking at all the other watchdog drivers, it does not appear that > > there is any other processor which uses a similar feature. Since imx is the > > only processor that appears to support this feature, it might make sense in > > making this vendor specific. If in the future it is found more processors > > support a similar functionality, it can be revisited and moved out from > > being vendor specific? > > > > I'm certainly no expert on device-tree policy. I understand your > point, but realize that the driver in question is imx2_wdt.c > (compatible = "fsl,imx21-wdt"). This is an IP block inside the silicon > of only Freescale chips, so its not like a future omap chip would be > using this driver - only fsl devices. So why would it need a 'vendor' > property any more than its other properties? > > Regards, > > Tim Wim, Does the lack of response mean overwhelming approval? I haven't heard any valid complaints - what does it take to get this approved? Regards, Tim -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] serial: support for 16550A serial ports on LP-8x4x
On Wed, 2015-12-16 at 00:04 +0300, Sergei Ianovich wrote:
> The patch adds support for 3 additional LP-8x4x built-in serial
> ports.
>
> The device can also host up to 8 extension cards with 4 serial ports
> on each card for a total of 35 ports. However, I don't have
> the hardware to test extension cards, so they are not supported, yet.
>
Few nitpicks, though everything looks okay.
> Signed-off-by: Sergei Ianovich
> Reviewed-by: Heikki Krogerus
> CC: Alan Cox
> ---
> v4..v5
> * constify struct of_device_id
> * drop .owner from struct platform_driver
> * rewrite set_termios() baud rate hadnling as suggested by Alan
> Cox
>
> v3..v4
> * move DTS bindings to a different patch (8/21) as suggested by
> Heikki Krogerus
>
> v2..v3
> * no changes (except number 10/16 -> 12/21)
>
> v0..v2
> * register platform driver instead of platform device
> * use device tree
> * use devm helpers where possible
>
> .../devicetree/bindings/serial/lp8x4x-serial.txt | 35 +
> drivers/tty/serial/8250/8250_lp8x4x.c | 168
> +
> drivers/tty/serial/8250/Kconfig| 12 ++
> drivers/tty/serial/8250/Makefile | 1 +
> 4 files changed, 216 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/serial/lp8x4x-
> serial.txt
> create mode 100644 drivers/tty/serial/8250/8250_lp8x4x.c
>
> diff --git a/Documentation/devicetree/bindings/serial/lp8x4x-
> serial.txt b/Documentation/devicetree/bindings/serial/lp8x4x-
> serial.txt
> new file mode 100644
> index 000..5f9a4c1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/lp8x4x-serial.txt
> @@ -0,0 +1,35 @@
> +UART ports on ICP DAS LP-8x4x
> +
> +ICP DAS LP-8x4x contains three additional serial ports interfaced
> via
> +Analog Devices ADM213EA chips in addition to 3 serial ports on PXA
> CPU.
> +
> +Required properties:
> +- compatible : should be "icpdas,uart-lp8x4x"
> +
> +- reg : should provide 16 byte man IO memory region and 1 byte
> region for
> + termios
> +
> +- interrupts : should provide interrupt
> +
> +- interrupt-parent : should provide a link to interrupt controller
> either
> + explicitly or implicitly from a parent node
> +
> +Examples (from pxa27x-lp8x4x.dts):
> +
> + uart@9050 {
> + compatible = "icpdas,uart-lp8x4x";
> + reg = <0x9050 0x10
> + 0x9030 0x02>;
> + interrupt-parent = <&fpgairg>;
> + interrupts = <13>;
> + status = "okay";
> + };
> +
> + uart@9060 {
> + compatible = "icpdas,uart-lp8x4x";
> + reg = <0x9060 0x10
> + 0x9032 0x02>;
> + interrupt-parent = <&fpgairg>;
> + interrupts = <14>;
> + status = "okay";
> + };
> diff --git a/drivers/tty/serial/8250/8250_lp8x4x.c
> b/drivers/tty/serial/8250/8250_lp8x4x.c
> new file mode 100644
> index 000..0e07220
> --- /dev/null
> +++ b/drivers/tty/serial/8250/8250_lp8x4x.c
> @@ -0,0 +1,168 @@
> +/* linux/drivers/tty/serial/8250/8250_lp8x4x.c
> + *
> + * Support for 16550A serial ports on ICP DAS LP-8x4x
> + *
> + * Copyright (C) 2013 Sergei Ianovich
> + *
> + * This program is free software; you can redistribute it and/or
> modify
> + * it under the terms of the GNU General Public License version 2
> as
> + * published by the Free Software Foundation.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct lp8x4x_serial_data {
> + int line;
> + void*ios_mem;
> +};
> +
> +static void lp8x4x_serial_set_termios(struct uart_port *port,
> + struct ktermios *termios, struct ktermios *old)
> +{
> + unsigned int len;
> + unsigned int baud;
> + struct lp8x4x_serial_data *data = port->private_data;
> +
> + serial8250_do_set_termios(port, termios, old);
> +
> + switch (termios->c_cflag & CSIZE) {
> + case CS5:
> + len = 7;
> + break;
> + case CS6:
> + len = 8;
> + break;
> + case CS7:
> + len = 9;
> + break;
> + default:
> + case CS8:
I would suggest to exchange those lines.
> + len = 10;
> + break;
> + }
> +
> + if (termios->c_cflag & CSTOPB)
> + len++;
> + if (termios->c_cflag & PARENB)
> + len++;
> + if (!(termios->c_cflag & PARODD))
> + len++;
> +#ifdef CMSPAR
> + if (termios->c_cflag & CMSPAR)
> + len++;
> +#endif
> +
> + len -= 9;
> + len &= 3;
> + len <<= 3;
> + /*
> + * Ask the core to calculate the divisor for us.
> + */
Can it be one line?
> + baud = tty_termios_baud_rate(termios);
> +
> +
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
Hello.
On 12/17/2015 3:53 AM, Krzysztof Kozlowski wrote:
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov
---
Changes in version 3:
- reformatted the change log.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
entry, the driver heading comment, the module description, and the change
log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig |8
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 153
4 files changed, 183 insertions(+)
Index: renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+Maxim Integrated MAX3355 USB OTG chip
+-
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
pin
+ connected to the MAX3355's SHDN# pin;
Could you add some indentation to the wrapped line for this property?
For readability.
If it's not indented enough, I can add more spaces/tabs.
+- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
Ditto.
Why this property lacks the vendor prefix i(n comparison to shdn-gpios
which has the prefix)?
Since the extcon-usb-gpio driver uses "id-gpio" prop already. I can add
back the vendor prefix if you insist.
[...]
Index: renesas/drivers/extcon/extcon-max3355.c
===
--- /dev/null
+++ renesas/drivers/extcon/extcon-max3355.c
@@ -0,0 +1,153 @@
[...]
+static int max3355_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct max3355_data *data;
+ struct gpio_desc *gpiod;
+ int irq, err;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(struct max3355_data),
+ GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->edev = devm_extcon_dev_allocate(&pdev->dev, max3355_cable);
+ if (IS_ERR(data->edev)) {
+ dev_err(&pdev->dev, "failed to allocate extcon device\n");
+ return PTR_ERR(data->edev);
+ }
+ data->edev->name = kstrdup(np->name, GFP_KERNEL);
I think it is not needed any more (extcon_dev_register()) will set it.
Anyway there is no checking for NULL return value and no freeing in
error/exit paths.
Oops, will fix.
[...]
+static struct platform_driver max3355_driver = {
+ .probe = max3355_probe,
+ .remove = max3355_remove,
+ .driver = {
+ .name = "extcon-max3355",
+ .of_match_table = max3355_match_table,
+ .owner = THIS_MODULE,
No need for owner.
Please pass the source through recent coccicheck and fix the findings.
Has it been included in the kernel source somewhere already?
Best regards,
Krzysztof
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
[PATCH v1 2/6] ARM: dts: add the lcdc and hdmi node for rk3036
The rk3036 support two overlay plane and one hwc plane,
it support IOMMU, and its IOMMU same as rk3288's.
Meanwhile, add the inno hdmi for HDMI display.
Signed-off-by: Caesar Wang
---
arch/arm/boot/dts/rk3036.dtsi | 61 +++
1 file changed, 61 insertions(+)
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 620e6e0..11a8078 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -145,6 +145,37 @@
};
};
+ lcdc_mmu: iommu@10118300 {
+ compatible = "rockchip,iommu";
+ reg = <0x10118300 0x100>;
+ interrupts = ;
+ interrupt-names = "lcdc_mmu";
+ #iommu-cells = <0>;
+ status = "disabled";
+ };
+
+ lcdc: lcdc@10118000 {
+ compatible = "rockchip,rk3036-lcdc";
+ reg = <0x10118000 0x19c>;
+ interrupts = ;
+ clocks = <&cru ACLK_LCDC>, <&cru SCLK_LCDC>, <&cru HCLK_LCDC>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ resets = <&cru SRST_LCDC1_A>, <&cru SRST_LCDC1_H>, <&cru
SRST_LCDC1_D>;
+ reset-names = "axi", "ahb", "dclk";
+ iommus = <&lcdc_mmu>;
+
+ status = "disabled";
+
+ lcdc_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ lcdc_out_hdmi: endpoint@0 {
+ reg = <1>;
+ remote-endpoint = <&hdmi_in_lcdc>;
+ };
+ };
+ };
+
gic: interrupt-controller@10139000 {
compatible = "arm,gic-400";
interrupt-controller;
@@ -248,6 +279,27 @@
status = "disabled";
};
+ hdmi: hdmi@20034000 {
+ compatible = "rockchip,rk3036-inno-hdmi";
+ reg = <0x20034000 0x4000>;
+ interrupts = ;
+ clocks = <&cru PCLK_HDMI>;
+ clock-names = "pclk";
+ rockchip,grf = <&grf>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_ctl>;
+ status = "disabled";
+
+ hdmi_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in_lcdc: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&lcdc_out_hdmi>;
+ };
+ };
+ };
+
timer: timer@20044000 {
compatible = "rockchip,rk3036-timer", "rockchip,rk3288-timer";
reg = <0x20044000 0x20>;
@@ -484,6 +536,15 @@
};
};
+ hdmi {
+ hdmi_ctl: hdmi-ctl {
+ rockchip,pins = <1 8 RK_FUNC_1
&pcfg_pull_none>,
+ <1 9 RK_FUNC_1
&pcfg_pull_none>,
+ <1 10 RK_FUNC_1
&pcfg_pull_none>,
+ <1 11 RK_FUNC_1
&pcfg_pull_none>;
+ };
+ };
+
i2c0 {
i2c0_xfer: i2c0-xfer {
rockchip,pins = <0 0 RK_FUNC_1 &pcfg_pull_none>,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 3/6] ARM: dts: add the sdio/sdmmc node for rk3036
In general, the sdio/sdmmc is used by the wifi module
and sd card.
let's add the node for these function.
Signed-off-by: Caesar Wang
---
arch/arm/boot/dts/rk3036.dtsi | 72 +++
1 file changed, 72 insertions(+)
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 11a8078..947d070 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -55,6 +55,8 @@
i2c1 = &i2c1;
i2c2 = &i2c2;
mshc0 = &emmc;
+ mshc1 = &sdmmc;
+ mshc2 = &sdio;
serial0 = &uart0;
serial1 = &uart1;
serial2 = &uart2;
@@ -215,6 +217,30 @@
status = "disabled";
};
+ sdmmc: dwmmc@10214000 {
+ compatible = "rockchip,rk3036-dw-mshc",
"rockchip,rk3288-dw-mshc";
+ clock-frequency = <3750>;
+ clock-freq-min-max = <40 3750>;
+ clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x100>;
+ interrupts = ;
+ reg = <0x10214000 0x4000>;
+ status = "disabled";
+ };
+
+ sdio: dwmmc@10218000 {
+ compatible = "rockchip,rk3036-dw-mshc",
"rockchip,rk3288-dw-mshc";
+ clock-freq-min-max = <40 3750>;
+ clocks = <&cru HCLK_SDIO>, <&cru SCLK_SDIO>,
+ <&cru SCLK_SDIO_DRV>, <&cru SCLK_SDIO_SAMPLE>;
+ clock-names = "biu", "ciu", "ciu_drv", "ciu_sample";
+ fifo-depth = <0x100>;
+ interrupts = ;
+ reg = <0x10218000 0x4000>;
+ status = "disabled";
+ };
+
emmc: dwmmc@1021c000 {
compatible = "rockchip,rk3288-dw-mshc";
reg = <0x1021c000 0x4000>;
@@ -511,6 +537,52 @@
};
};
+ sdmmc {
+ sdmmc_clk: sdmmc-clk {
+ rockchip,pins = <1 16 RK_FUNC_1
&pcfg_pull_none>;
+ };
+
+ sdmmc_cmd: sdmmc-cmd {
+ rockchip,pins = <1 15 RK_FUNC_1
&pcfg_pull_default>;
+ };
+
+ sdmmc_cd: sdmcc-cd {
+ rockchip,pins = <1 17 RK_FUNC_1
&pcfg_pull_default>;
+ };
+
+ sdmmc_bus1: sdmmc-bus1 {
+ rockchip,pins = <1 18 RK_FUNC_1
&pcfg_pull_default>;
+ };
+
+ sdmmc_bus4: sdmmc-bus4 {
+ rockchip,pins = <1 18 RK_FUNC_1
&pcfg_pull_default>,
+ <1 19 RK_FUNC_1
&pcfg_pull_default>,
+ <1 20 RK_FUNC_1
&pcfg_pull_default>,
+ <1 21 RK_FUNC_1
&pcfg_pull_default>;
+ };
+ };
+
+ sdio {
+ sdio_bus1: sdio-bus1 {
+ rockchip,pins = <0 11 RK_FUNC_1
&pcfg_pull_default>;
+ };
+
+ sdio_bus4: sdio-bus4 {
+ rockchip,pins = <0 11 RK_FUNC_1
&pcfg_pull_default>,
+ <0 12 RK_FUNC_1
&pcfg_pull_default>,
+ <0 13 RK_FUNC_1
&pcfg_pull_default>,
+ <0 14 RK_FUNC_1
&pcfg_pull_default>;
+ };
+
+ sdio_cmd: sdio-cmd {
+ rockchip,pins = <0 8 RK_FUNC_1
&pcfg_pull_default>;
+ };
+
+ sdio_clk: sdio-clk {
+ rockchip,pins = <0 9 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
emmc {
/*
* We run eMMC at max speed; bump up drive strength.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 1/6] ARM: dts: fix the correct pinctrl control for rk3036
The pinctrl gpio pull up/down is incorrect since the rk3036 SoCs
can't set the status in the internal.
We should keep the default status for enable the gpio status,
In fact, the pull_none is the disable the gpio pull up/down.
Signed-off-by: Xing Zheng
Signed-off-by: Caesar Wang
---
arch/arm/boot/dts/rk3036.dtsi | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index f8758bf..620e6e0 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -427,12 +427,8 @@
#interrupt-cells = <2>;
};
- pcfg_pull_up: pcfg-pull-up {
- bias-pull-up;
- };
-
- pcfg_pull_down: pcfg-pull-down {
- bias-pull-down;
+ pcfg_pull_default: pcfg_pull_default {
+ bias-pull-pin-default;
};
pcfg_pull_none: pcfg-pull-none {
@@ -473,18 +469,18 @@
};
emmc_cmd: emmc-cmd {
- rockchip,pins = <2 1 RK_FUNC_2 &pcfg_pull_none>;
+ rockchip,pins = <2 1 RK_FUNC_2
&pcfg_pull_default>;
};
emmc_bus8: emmc-bus8 {
- rockchip,pins = <1 24 RK_FUNC_2
&pcfg_pull_none>,
- <1 25 RK_FUNC_2
&pcfg_pull_none>,
- <1 26 RK_FUNC_2
&pcfg_pull_none>,
- <1 27 RK_FUNC_2
&pcfg_pull_none>,
- <1 28 RK_FUNC_2
&pcfg_pull_none>,
- <1 29 RK_FUNC_2
&pcfg_pull_none>,
- <1 30 RK_FUNC_2
&pcfg_pull_none>,
- <1 31 RK_FUNC_2
&pcfg_pull_none>;
+ rockchip,pins = <1 24 RK_FUNC_2
&pcfg_pull_default>,
+ <1 25 RK_FUNC_2
&pcfg_pull_default>,
+ <1 26 RK_FUNC_2
&pcfg_pull_default>,
+ <1 27 RK_FUNC_2
&pcfg_pull_default>,
+ <1 28 RK_FUNC_2
&pcfg_pull_default>,
+ <1 29 RK_FUNC_2
&pcfg_pull_default>,
+ <1 30 RK_FUNC_2
&pcfg_pull_default>,
+ <1 31 RK_FUNC_2
&pcfg_pull_default>;
};
};
@@ -522,12 +518,12 @@
uart0 {
uart0_xfer: uart0-xfer {
- rockchip,pins = <0 16 RK_FUNC_1 &pcfg_pull_up>,
+ rockchip,pins = <0 16 RK_FUNC_1
&pcfg_pull_default>,
<0 17 RK_FUNC_1
&pcfg_pull_none>;
};
uart0_cts: uart0-cts {
- rockchip,pins = <0 18 RK_FUNC_1 &pcfg_pull_up>;
+ rockchip,pins = <0 18 RK_FUNC_1
&pcfg_pull_default>;
};
uart0_rts: uart0-rts {
@@ -537,7 +533,7 @@
uart1 {
uart1_xfer: uart1-xfer {
- rockchip,pins = <2 22 RK_FUNC_1
&pcfg_pull_none>,
+ rockchip,pins = <2 22 RK_FUNC_1
&pcfg_pull_default>,
<2 23 RK_FUNC_1
&pcfg_pull_none>;
};
/* no rts / cts for uart1 */
@@ -545,7 +541,7 @@
uart2 {
uart2_xfer: uart2-xfer {
- rockchip,pins = <1 18 RK_FUNC_2
&pcfg_pull_none>,
+ rockchip,pins = <1 18 RK_FUNC_2
&pcfg_pull_default>,
<1 19 RK_FUNC_2
&pcfg_pull_none>;
};
/* no rts / cts for uart2 */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 5/6] ARM: dts: add the sound codec for kylin board
Support the rt5616 codec for kylin board, but we need
enable the i2s firstly.
Signed-off-by: Caesar Wang
---
arch/arm/boot/dts/rk3036-kylin.dts | 33 +
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/rk3036-kylin.dts
b/arch/arm/boot/dts/rk3036-kylin.dts
index 69b1e1e..296139b 100644
--- a/arch/arm/boot/dts/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -46,6 +46,28 @@
model = "Rockchip RK3036 KylinBoard";
compatible = "rockchip,rk3036-kylin", "rockchip,rk3036";
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,name = "rockchip,rt5616-codec";
+ simple-audio-card,mclk-fs = <64>;
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack";
+ simple-audio-card,routing =
+ "MIC1", "Microphone Jack",
+ "MIC2", "Microphone Jack",
+ "Microphone Jack", "micbias1",
+ "Headphone Jack", "HPOL",
+ "Headphone Jack", "HPOR";
+ simple-audio-card,cpu {
+ sound-dai = <&i2s>;
+ };
+ simple-audio-card,codec {
+ sound-dai = <&rt5616>;
+ };
+ };
+
vcc_sys: vsys-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
@@ -261,6 +283,17 @@
&i2c2 {
status = "okay";
+
+ rt5616: rt5616@1b {
+ #sound-dai-cells = <0>;
+ compatible = "rt5616";
+ reg = <0x1b>;
+ };
+};
+
+&i2s {
+ #sound-dai-cells = <0>;
+ status = "okay";
};
&lcdc {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 4/6] ARM: dts: rockchip: add the kylin board for rk3036
This patchset is the initiation version to try work
for kylin board.
Signed-off-by: Caesar Wang
---
Documentation/devicetree/bindings/arm/rockchip.txt | 4 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk3036-kylin.dts | 298 +
3 files changed, 303 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3036-kylin.dts
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
b/Documentation/devicetree/bindings/arm/rockchip.txt
index c40c091..56653c4 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -1,6 +1,10 @@
Rockchip platforms device tree bindings
---
+- Kylin RK3036 board:
+Required root node properties:
+ - compatible = "rockchip,kylin-rk3036", "rockchip,rk3036";
+
- MarsBoard RK3066 board:
Required root node properties:
- compatible = "haoyu,marsboard-rk3066", "rockchip,rk3066a";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5e284dd..b911601 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -513,6 +513,7 @@ dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3036-evb.dtb \
+ rk3036-kylin.dtb \
rk3066a-bqcurie2.dtb \
rk3066a-marsboard.dtb \
rk3066a-rayeager.dtb \
diff --git a/arch/arm/boot/dts/rk3036-kylin.dts
b/arch/arm/boot/dts/rk3036-kylin.dts
new file mode 100644
index 000..69b1e1e
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -0,0 +1,298 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk3036.dtsi"
+
+/ {
+ model = "Rockchip RK3036 KylinBoard";
+ compatible = "rockchip,rk3036-kylin", "rockchip,rk3036";
+
+ vcc_sys: vsys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+};
+
+&acodec {
+ status = "okay";
+};
+
+&emmc {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <40>;
+
+ status = "okay";
+
+ rk808: pmic@1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int &global_pwroff>;
+ rockchip,system-power-controller;
+ wakeup-source;
+ #clock-cells = <1>;
+ clock-output-names = "xin32k", "rk808-clkout2";
+
+ vcc1-supply = <&vcc_sys>;
+ vcc2-supply = <&vcc_sys>;
+ vcc3-supply = <&vcc_sys>;
+ vcc4-supply = <&vcc_sys>;
+ vcc6-supply = <&vcc_sys>;
+
[PATCH v1 6/6] ARM: dts: add the sdio node for kylin board
Let's enable the sdio for wifi module on kylin board.
Signed-off-by: Caesar Wang
---
arch/arm/boot/dts/rk3036-kylin.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/rk3036-kylin.dts
b/arch/arm/boot/dts/rk3036-kylin.dts
index 296139b..581e954 100644
--- a/arch/arm/boot/dts/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -304,6 +304,20 @@
status = "okay";
};
+&sdio {
+ status = "okay";
+
+ broken-cd;
+ bus-width = <4>;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ non-removable;
+ num-slots = <1>;
+ default-sample-phase = <90>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdio_clk &sdio_cmd &sdio_bus4>;
+};
+
&uart2 {
status = "okay";
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 0/6] Support the rk3036 Kylin board
Kylin-board is based on RK3036 SOCs, add the initiation version for working. This series patches have the following decriptions: PATCH[1/6]: ARM: dts: fix the correct pinctrl control for rk3036 The pinctrl gpio pull up/down is incorrect since the rk3036 SoCs can't set the status in the internal. --- PATCH[2/6]: ARM: dts: add the lcdc and hdmi node for rk3036 Add the devices is related to display. Based on the series patches of Mark Yao's --- PATCH[3/6]: ARM: dts: add the sdio/sdmmc node for rk3036 Add the wifi/sd card work for kylin board. --- PATCH[4/6]: ARM: dts: rockchip: add the kylin board for rk3036 Add the dts for kylin board. --- PATCH[5/6]: ARM: dts: add the sound codec for kylin board Make the codec rt5616 working on kylin board. The realteak have been upstream for Mark Brown, I guess need some days to review. --- PATCH[6/6]: ARM: dts: add the sdio node for kylin board Enable the sdio for kylin board. --- Caesar Wang (6): ARM: dts: fix the correct pinctrl control for rk3036 ARM: dts: add the lcdc and hdmi node for rk3036 ARM: dts: add the sdio/sdmmc node for rk3036 ARM: dts: rockchip: add the kylin board for rk3036 ARM: dts: add the sound codec for kylin board ARM: dts: add the sdio node for kylin board Documentation/devicetree/bindings/arm/rockchip.txt | 4 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3036-kylin.dts | 345 + arch/arm/boot/dts/rk3036.dtsi | 167 -- 4 files changed, 498 insertions(+), 19 deletions(-) create mode 100644 arch/arm/boot/dts/rk3036-kylin.dts -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
On Wed, Dec 16, 2015 at 8:31 PM, Peter Chen wrote:
> On Thu, Dec 17, 2015 at 12:13:07AM +0100, Arnd Bergmann wrote:
>> On Wednesday 16 December 2015 16:59:39 Rob Herring wrote:
>> > On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote:
>> > > On Monday 14 December 2015 15:26:11 Peter Chen wrote:
>> >
>> > I agree on doing it properly, but am not sure that pwrseq binding for
>> > MMC is proper. The pwrseq binding is fairly limited and working around
>> > the driver model IMO. Hubs may also need I2C setup which I don't think
>> > could be done generically other than some defined sequence of i2c
>> > transactions. The current project I'm working on needs to use I2C to
>> > configure the hub to use HSIC mode for example. I really think we need
>> > a pre-probe driver hook to handle this. That would allow device
>> > specific setup to live in the driver.
>> >
>> > Perhaps a more simple approach would be just forcing driver probe if a
>> > DT node is present. I'm not all that familiar with USB drivers, but
>> > presumably there is some setup before probe like setting the USB
>> > device address. We'd have to allow doing that later during probe.
>>
>> Yes, good idea. I was also advocating that approach for MMC at some
>> point, but the power sequencing made it in the end.
>>
>
> Currently, my design is much like Rob proposal's. I will populate all
> children device under HUB's node (controller = 1st level hub), and
> each special onboard USB device needs a platform driver, it can be
> probed according to compatible string, and at its probe, it can register
> itself as usb device if needed, and handle properties described at
> its node. Sample code like below:
It is not like my proposal because I don't think the design should be
using a platform driver.
> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> index 8263fc1..7451f7d 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> @@ -590,6 +590,16 @@
> &usbh1 {
> vbus-supply = <®_usb_h1_vbus>;
> status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + hub: usb2415@01 {
> + compatible = "generic-onboard-hub";
Please follow the already defined naming scheme for USB devices.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 0/2] ARM: DTS: am33xx/am437x: Use the new eDMA bindings
Hi, Changes since v1: - Updated to use the non 16bit arrays [1] - send the two patch as a series [1] As it has been discussed earlier: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html the DT bindings has been changes compared to what we had in 4.4-rc1: the arrays now don't have the 16bit type. The changes are now merged to mainline and Vinod provided us a branch: git://git.infradead.org/users/vkoul/slave-dma.git fix/edma Which is based on 4.4-rc1 and only contains the two patch for changing the eDMA bindings. Regards, Peter --- Peter Ujfalusi (2): ARM: DTS: am33xx: Use the new DT bindings for the eDMA3 ARM: DTS: am437x: Use the new DT bindings for the eDMA3 arch/arm/boot/dts/am335x-evm.dts| 9 +--- arch/arm/boot/dts/am335x-pepper.dts | 11 + arch/arm/boot/dts/am33xx.dtsi | 94 ++--- arch/arm/boot/dts/am4372.dtsi | 80 +++ arch/arm/boot/dts/am437x-gp-evm.dts | 9 +--- 5 files changed, 133 insertions(+), 70 deletions(-) -- 2.6.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 2/2] ARM: DTS: am437x: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/am4372.dtsi | 80 +++--
arch/arm/boot/dts/am437x-gp-evm.dts | 9 +
2 files changed, 62 insertions(+), 27 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index e363af1e17c6..ddcb92ebebbc 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -172,6 +172,14 @@
mboxes = <&mailbox &mbox_wkupm3>;
};
+ edma_xbar: dma-router@f90 {
+ compatible = "ti,am335x-edma-crossbar";
+ reg = <0xf90 0x40>;
+ #dma-cells = <3>;
+ dma-requests = <64>;
+ dma-masters = <&edma>;
+ };
+
scm_clockdomains: clockdomains {
};
};
@@ -184,14 +192,46 @@
};
edma: edma@4900 {
- compatible = "ti,edma3";
- ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
- reg = <0x4900 0x1>,
- <0x44e10f90 0x10>;
+ compatible = "ti,edma3-tpcc";
+ ti,hwmods = "tpcc";
+ reg = <0x4900 0x1>;
+ reg-names = "edma3_cc";
interrupts = ,
- ,
- ;
- #dma-cells = <1>;
+,
+;
+ interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 5>,
+ <&edma_tptc2 0>;
+
+ ti,edma-memcpy-channels = <32 33>;
+ };
+
+ edma_tptc0: tptc@4980 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc0";
+ reg = <0x4980 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc1: tptc@4990 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc1";
+ reg = <0x4990 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc2: tptc@49a0 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc2";
+ reg = <0x49a0 0x10>;
+ interrupts = ;
+ interrupt-names = "edma3_tcerrint";
};
uart0: serial@44e09000 {
@@ -496,8 +536,8 @@
ti,hwmods = "mmc1";
ti,dual-volt;
ti,needs-special-reset;
- dmas = <&edma 24
- &edma 25>;
+ dmas = <&edma 24 0>,
+ <&edma 25 0>;
dma-names = "tx", "rx";
interrupts = ;
status = "disabled";
@@ -508,8 +548,8 @@
reg = <0x481d8000 0x1000>;
ti,hwmods = "mmc2";
ti,needs-special-reset;
- dmas = <&edma 2
- &edma 3>;
+ dmas = <&edma 2 0>,
+ <&edma 3 0>;
dma-names = "tx", "rx";
interrupts = ;
status = "disabled";
@@ -777,7 +817,7 @@
compatible = "ti,omap5-sham";
ti,hwmods = "sham";
reg = <0x5310 0x300>;
- dmas = <&edma 36>;
+ dmas = <&edma 36 0>;
dma-names = "rx";
interrupts = ;
};
@@ -787,8 +827,8 @@
ti,hwmo
[PATCH v02 1/2] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/am335x-evm.dts| 9 +---
arch/arm/boot/dts/am335x-pepper.dts | 11 +
arch/arm/boot/dts/am33xx.dtsi | 94 ++---
3 files changed, 71 insertions(+), 43 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 4caf074063fe..a55072fb6646 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -743,8 +743,8 @@
&mmc3 {
/* these are on the crossbar and are outlined in the
xbar-event-map element */
- dmas = <&edma 12
- &edma 13>;
+ dmas = <&edma_xbar 12 0 1
+ &edma_xbar 13 0 2>;
dma-names = "tx", "rx";
status = "okay";
vmmc-supply = <&wlan_en_reg>;
@@ -766,11 +766,6 @@
};
};
-&edma {
- ti,edma-xbar-event-map = /bits/ 16 <1 12
- 2 13>;
-};
-
&sham {
status = "okay";
};
diff --git a/arch/arm/boot/dts/am335x-pepper.dts
b/arch/arm/boot/dts/am335x-pepper.dts
index 9cb77a120319..4dd4f71498e5 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -339,13 +339,6 @@
ti,non-removable;
};
-&edma {
- /* Map eDMA MMC2 Events from Crossbar */
- ti,edma-xbar-event-map = /bits/ 16 <1 12
-2 13>;
-};
-
-
&mmc3 {
/* Wifi & Bluetooth on MMC #3 */
status = "okay";
@@ -354,8 +347,8 @@
vmmmc-supply = <&v3v3c_reg>;
bus-width = <4>;
ti,non-removable;
- dmas = <&edma 12
- &edma 13>;
+ dmas = <&edma_xbar 12 0 1
+ &edma_xbar 13 0 2>;
dma-names = "tx", "rx";
};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9b8861891bf0..04885f9f959e 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -161,6 +161,14 @@
mboxes = <&mailbox &mbox_wkupm3>;
};
+ edma_xbar: dma-router@f90 {
+ compatible = "ti,am335x-edma-crossbar";
+ reg = <0xf90 0x40>;
+ #dma-cells = <3>;
+ dma-requests = <32>;
+ dma-masters = <&edma>;
+ };
+
scm_clockdomains: clockdomains {
};
};
@@ -174,12 +182,44 @@
};
edma: edma@4900 {
- compatible = "ti,edma3";
- ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
- reg = <0x4900 0x1>,
- <0x44e10f90 0x40>;
+ compatible = "ti,edma3-tpcc";
+ ti,hwmods = "tpcc";
+ reg = <0x4900 0x1>;
+ reg-names = "edma3_cc";
interrupts = <12 13 14>;
- #dma-cells = <1>;
+ interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+ dma-requests = <64>;
+ #dma-cells = <2>;
+
+ ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 5>,
+ <&edma_tptc2 0>;
+
+ ti,edma-memcpy-channels = <20 21>;
+ };
+
+ edma_tptc0: tptc@4980 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc0";
+ reg = <0x4980 0x10>;
+ interrupts = <112>;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc1: tptc@4990 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc1";
+ reg = <0x4990 0x10>;
+ interrupts = <113>;
+ interrupt-names = "edma3_tcerrint";
+ };
+
+ edma_tptc2: tptc@49a0 {
+ compatible = "ti,edma3-tptc";
+ ti,hwmods = "tptc2";
+ reg = <0x49a0 0x10>;
+ interrupts = <114>;
+ interrupt
[PATCH v02 5/6] ARM: DTS: da850: Add node for mmc1
da850 has two MMC controller, MMCSD1 is served by eDMA1
Signed-off-by: Peter Ujfalusi
Tested-by: Sushaanth Srirangapathi
---
arch/arm/boot/dts/da850.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 1538959f2853..31ca5768fccf 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -239,6 +239,14 @@
dma-names = "rx", "tx";
status = "disabled";
};
+ mmc1: mmc@1e1b000 {
+ compatible = "ti,da830-mmc";
+ reg = <0x21b000 0x1000>;
+ interrupts = <72>;
+ dmas = <&edma1 28 0>, <&edma1 29 0>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
ehrpwm0: ehrpwm@01f0 {
compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 2/6] ARM: DTS: da850: Use the new DT bindings for the eDMA3
Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.
Using the new binding will allow us to reserve PaRAM slots to be used by
the DSP which was not possible before and prevented the da850 boards to be
moved to DT only.
Note that the DMA memcpy is disabled, it can be enabled by reserving
channels for memcpy by adding the following property to the edma node:
ti,edma-memcpy-channels = <20 21>; /* Reserving channel 20 and 21 for memcpy */
Signed-off-by: Peter Ujfalusi
Tested-by: Sushaanth Srirangapathi
---
arch/arm/boot/dts/da850-enbw-cmc.dts | 4
arch/arm/boot/dts/da850-evm.dts | 4
arch/arm/boot/dts/da850.dtsi | 26 +-
3 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/da850-enbw-cmc.dts
b/arch/arm/boot/dts/da850-enbw-cmc.dts
index e750ab9086d5..1811f8275559 100644
--- a/arch/arm/boot/dts/da850-enbw-cmc.dts
+++ b/arch/arm/boot/dts/da850-enbw-cmc.dts
@@ -28,3 +28,7 @@
};
};
};
+
+&edma0 {
+ ti,edma-reserved-slot-ranges = <32 50>;
+};
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index d807285a61cd..94cf9a9b1302 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -243,3 +243,7 @@
tx-num-evt = <32>;
rx-num-evt = <32>;
};
+
+&edma0 {
+ ti,edma-reserved-slot-ranges = <32 50>;
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index e73f5efb3aa3..6e39f9b06524 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -151,11 +151,27 @@
};
edma0: edma@01c0 {
- compatible = "ti,edma3";
+ compatible = "ti,edma3-tpcc";
/* eDMA3 CC0: 0x01c0 - 0x01c0 7fff */
reg = <0x0 0x8000>;
- interrupts = <11 13 12>;
- #dma-cells = <1>;
+ reg-names = "edma3_cc";
+ interrupts = <11 12>;
+ interrupt-names = "edma3_ccint", "edma3_ccerrint";
+ #dma-cells = <2>;
+
+ ti,tptcs = <&edma0_tptc0 7>, <&edma0_tptc1 0>;
+ };
+ edma0_tptc0: tptc@01c08000 {
+ compatible = "ti,edma3-tptc";
+ reg = <0x8000 0x400>;
+ interrupts = <13>;
+ interrupt-names = "edm3_tcerrint";
+ };
+ edma0_tptc1: tptc@01c08400 {
+ compatible = "ti,edma3-tptc";
+ reg = <0x8400 0x400>;
+ interrupts = <32>;
+ interrupt-names = "edm3_tcerrint";
};
serial0: serial@1c42000 {
compatible = "ns16550a";
@@ -286,8 +302,8 @@
interrupts = <54>;
interrupt-names = "common";
status = "disabled";
- dmas = <&edma0 1>,
- <&edma0 0>;
+ dmas = <&edma0 1 1>,
+ <&edma0 0 1>;
dma-names = "tx", "rx";
};
};
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 4/6] ARM: DTS: da850: Enable DMA use for MMC0
Add the needed bindings for MMC0 in order to be able to utilize the DMA
instead of PIO mode.
Signed-off-by: Peter Ujfalusi
Tested-by: Sushaanth Srirangapathi
---
arch/arm/boot/dts/da850.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index c08b6c04fcf1..1538959f2853 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -235,6 +235,8 @@
compatible = "ti,da830-mmc";
reg = <0x4 0x1000>;
interrupts = <16>;
+ dmas = <&edma0 16 0>, <&edma0 17 0>;
+ dma-names = "rx", "tx";
status = "disabled";
};
ehrpwm0: ehrpwm@01f0 {
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 1/6] ARM: DTS: da850: fix edma0 reg space
The size of the eDMA0 CC register space is 0x8000 and not 0x1.
Signed-off-by: Peter Ujfalusi
Tested-by: Sushaanth Srirangapathi
---
arch/arm/boot/dts/da850.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 0bd98cd00816..e73f5efb3aa3 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -152,7 +152,8 @@
};
edma0: edma@01c0 {
compatible = "ti,edma3";
- reg = <0x0 0x1>;
+ /* eDMA3 CC0: 0x01c0 - 0x01c0 7fff */
+ reg = <0x0 0x8000>;
interrupts = <11 13 12>;
#dma-cells = <1>;
};
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 3/6] ARM: DTS: da850: Enable eDMA1
The eDMA1 in da850 has only one TPTC and for example MMC1 is HW events are
handled by it.
Signed-off-by: Peter Ujfalusi
Tested-by: Sushaanth Srirangapathi
---
arch/arm/boot/dts/da850-enbw-cmc.dts | 4
arch/arm/boot/dts/da850-evm.dts | 4
arch/arm/boot/dts/da850.dtsi | 17 +
3 files changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/da850-enbw-cmc.dts
b/arch/arm/boot/dts/da850-enbw-cmc.dts
index 1811f8275559..645549e14237 100644
--- a/arch/arm/boot/dts/da850-enbw-cmc.dts
+++ b/arch/arm/boot/dts/da850-enbw-cmc.dts
@@ -32,3 +32,7 @@
&edma0 {
ti,edma-reserved-slot-ranges = <32 50>;
};
+
+&edma1 {
+ ti,edma-reserved-slot-ranges = <32 90>;
+};
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 94cf9a9b1302..30e2def402ad 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -247,3 +247,7 @@
&edma0 {
ti,edma-reserved-slot-ranges = <32 50>;
};
+
+&edma1 {
+ ti,edma-reserved-slot-ranges = <32 90>;
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 6e39f9b06524..c08b6c04fcf1 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -173,6 +173,23 @@
interrupts = <32>;
interrupt-names = "edm3_tcerrint";
};
+ edma1: edma@01e3 {
+ compatible = "ti,edma3-tpcc";
+ /* eDMA3 CC1: 0x01e3 - 0x01e3 7fff */
+ reg = <0x23 0x8000>;
+ reg-names = "edma3_cc";
+ interrupts = <93 94>;
+ interrupt-names = "edma3_ccint", "edma3_ccerrint";
+ #dma-cells = <2>;
+
+ ti,tptcs = <&edma1_tptc0 7>;
+ };
+ edma1_tptc0: tptc@01e38000 {
+ compatible = "ti,edma3-tptc";
+ reg = <0x238000 0x400>;
+ interrupts = <95>;
+ interrupt-names = "edm3_tcerrint";
+ };
serial0: serial@1c42000 {
compatible = "ns16550a";
reg = <0x42000 0x100>;
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 6/6] ARM: DTS: da850: Enable DMA for SPI1
Add the needed bindings so the SPI driver can use DMA with SPI1.
Signed-off-by: Peter Ujfalusi
Tested-by: Sushaanth Srirangapathi
---
arch/arm/boot/dts/da850.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 31ca5768fccf..226cda76e77c 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -285,6 +285,8 @@
num-cs = <4>;
ti,davinci-spi-intr-line = <1>;
interrupts = <56>;
+ dmas = <&edma0 18 0>, <&edma0 19 0>;
+ dma-names = "rx", "tx";
status = "disabled";
};
mdio: mdio@1e24000 {
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v02 0/6] ARM: DTS: da850: eDMA new bindings and MMC/SPI DMA support
Hi, Changes since v1: - Added tested by from Sushaanth Srirangapathi - Updated to use the non 16bit arrays [1] - memcpy channels are not reserved as requested by Sekhar - DMA memcpy is disabled for now Switch to use the new eDMA bindings and enable DMA for MMC0, SPI1. Add node for MMC1. [1] As it has been discussed in the following thread: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html the DT bindings has been changes compared to what we had in 4.4-rc1: the arrays now don't have the 16bit type. The changes are now merged to mainline and Vinod provided us a branch: git://git.infradead.org/users/vkoul/slave-dma.git fix/edma Which is based on 4.4-rc1 and only contains the two patch for changing the eDMA bindings. Regards, Peter --- Peter Ujfalusi (6): ARM: DTS: da850: fix edma0 reg space ARM: DTS: da850: Use the new DT bindings for the eDMA3 ARM: DTS: da850: Enable eDMA1 ARM: DTS: da850: Enable DMA use for MMC0 ARM: DTS: da850: Add node for mmc1 ARM: DTS: da850: Enable DMA for SPI1 arch/arm/boot/dts/da850-enbw-cmc.dts | 8 + arch/arm/boot/dts/da850-evm.dts | 8 + arch/arm/boot/dts/da850.dtsi | 58 3 files changed, 68 insertions(+), 6 deletions(-) -- 2.6.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/5] PCI: qcom: Add Qualcomm PCIe controller driver
Bjorn, thanks for the comments!
On 12/16/2015 11:53 PM, Bjorn Helgaas wrote:
> On Thu, Dec 03, 2015 at 03:35:22PM +0200, Stanimir Varbanov wrote:
>> From: Stanimir Varbanov
>>
>> The PCIe driver reuse the Designware common code for host
>> and MSI initialization, and also program the Qualcomm
>> application specific registers.
>>
>> Signed-off-by: Stanimir Varbanov
>> Signed-off-by: Stanimir Varbanov
>> ---
>> MAINTAINERS |7 +
>> drivers/pci/host/Kconfig | 10 +
>> drivers/pci/host/Makefile|1 +
>> drivers/pci/host/pcie-qcom.c | 624
>> ++
>
>> +#define PCIE20_CAP 0x70
>> +#define PCIE20_CAP_LINKCTRLSTATUS (PCIE20_CAP + 0x10)
>> +#define PCIE20_CAP_LINKCTRLSTATUS_LINK_UP BIT(29)
>
> This looks like it could be referring to a standard PCIe Capability;
> could you use the existing PCI_EXP_LNKSTA and PCI_EXP_LNKSTA_DLLLA
> symbols here? And readw() instead of readl()?
Yes, that is possible but I still need to keep PCIE20_CAP capabilities
offset.
>
>> +static int qcom_pcie_enable_link_training(struct qcom_pcie *pcie)
>> +{
>> +struct device *dev = pcie->dev;
>> +u32 val;
>> +int ret;
>> +
>> +/* enable link training */
>> +val = readl(pcie->elbi + PCIE20_ELBI_SYS_CTRL);
>> +val |= PCIE20_ELBI_SYS_CTRL_LT_ENABLE;
>> +writel(val, pcie->elbi + PCIE20_ELBI_SYS_CTRL);
>> +
>> +/* wait for up to 100ms for the link to come up */
>> +ret = readl_poll_timeout(pcie->elbi + PCIE20_ELBI_SYS_STTS, val,
>> + val & XMLH_LINK_UP, LINKUP_DELAY_US,
>> + LINKUP_TIMEOUT_US);
>> +
>> +if (ret < 0 || !dw_pcie_link_up(&pcie->pp)) {
>> +dev_err(dev, "link initialization failed\n");
>> +return -ETIMEDOUT;
>> +}
>> +
>> +return 0;
>> +}
>
> This looks a lot like the *_establish_link() functions in other
> DesignWare-based drivers. Can you make it look even more similar,
> e.g., by renaming it to qcom_pcie_establish_link() and maybe moving
> some of the PHY functionality here?
>
> readl_poll_timeout() is nice and avoids the hand-coded timeout loop
> the other drivers use. But is there benefit in checking for
> XMLH_LINK_UP, or could you simply poll dw_pcie_link_up() like the
> others do? If it's sufficient, I'd prefer using dw_pcie_link_up()
> by itself because it's a little more generic.
OK I will modify the code to use dw_pcie_link_up() and ensure that this
check is sufficient.
--
regards,
Stan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 04/10] serial: mps2-uart: add MPS2 UART driver
On Tue, Dec 15, 2015 at 2:40 PM, Vladimir Murzin
wrote:
> On 12/12/15 23:39, Andy Shevchenko wrote:
>> On Wed, Dec 2, 2015 at 11:33 AM, Vladimir Murzin
>> wrote:
>>> This driver adds support to the UART controller found on ARM MPS2
>>> platform.
>>
>> Just few comments (have neither time not big desire to do full review).
>>
>
> Still better than nothing ;) I'm mostly agree on points you had, so I've
> just left some I'm doubt about...
>
>>> +
>>> +static void mps2_uart_enable_ms(struct uart_port *port)
>>> +{
>>> +}
>>> +
>>> +static void mps2_uart_break_ctl(struct uart_port *port, int ctl)
>>> +{
>>> +}
>>
>> Are those required to be present? If not, remove them until you have
>> alive code there.
>
> A quick grep shows that core calls mps2_uart_break_ctl()
> unconditionally, but, yes, it checks for presence of
> mps2_uart_enable_ms() before jumping there, so it is safe to remove latter.
OK.
>>> +static irqreturn_t mps2_uart_oerrirq(int irq, void *data)
>>> +{
>>> + irqreturn_t handled = IRQ_NONE;
>>> + struct uart_port *port = data;
>>> + u8 irqflag = mps2_uart_read8(port, UARTn_INT);
>>> +
>>> + spin_lock(&port->lock);
>>> +
>>> + if (irqflag & UARTn_INT_RX_OVERRUN) {
>>> + struct tty_port *tport = &port->state->port;
>>> +
>>> + mps2_uart_write8(port, UARTn_INT_RX_OVERRUN, UARTn_INT);
>>> + tty_insert_flip_char(tport, 0, TTY_OVERRUN);
>>> + port->icount.overrun++;
>>> + handled = IRQ_HANDLED;
>>> + }
>>> +
>>> + /* XXX: this shouldn't happen? */
>>
>> If shouldn't why it's there? Otherwise better to explain which
>> conditions may lead to this.
>>
>
> In practice I've never seen that happened and I think it never *should*
> happen since we check if there is room in TX buffer. However, I could be
> wrong here, so it is why that statement has question mark.
So, worth to have a proper comment then.
>>> +static int __init mps2_uart_init(void)
>>> +{
>>> + int ret;
>>> +
>>> + ret = uart_register_driver(&mps2_uart_driver);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = platform_driver_register(&mps2_serial_driver);
>>> + if (ret)
>>> + uart_unregister_driver(&mps2_uart_driver);
>>> +
>>> + pr_info("MPS2 UART driver initialized\n");
>>> +
>>> + return ret;
>>> +}
>>> +module_init(mps2_uart_init);
>>> +
>>> +static void __exit mps2_uart_exit(void)
>>> +{
>>> + platform_driver_unregister(&mps2_serial_driver);
>>> + uart_unregister_driver(&mps2_uart_driver);
>>> +}
>>> +module_exit(mps2_uart_exit);
>>
>> module_platform_driver();
>> And move uart_*register calls to probe/remove.
>>
>
> With this move we'll get uart_*register for every device probed, no?
Don't see a problem, maybe someone else could share an authoritive opinion.
Some of the drivers do that, though most do in __init stage. So, see above.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] of: fix declaration of of_io_request_and_map
On 12/08/2015 09:47 AM, Sudip Mukherjee wrote:
We are having build failure with linux-next for sparc allmodconfig with
the error messages:
drivers/built-in.o: In function `meson6_timer_init':
meson6_timer.c:(.init.text+0x5fe8): undefined reference to
`of_io_request_and_map'
drivers/built-in.o: In function `mtk_timer_init':
mtk_timer.c:(.init.text+0x6af0): undefined reference to `of_io_request_and_map'
drivers/built-in.o: In function `asm9260_timer_init':
asm9260_timer.c:(.init.text+0x6c48): undefined reference to
`of_io_request_and_map'
CONFIG_OF is defined for sparc so it is expected that we have a
definition of of_io_request_and_map() but of/address.c is only compiled
if it is !SPARC. In other words, CONFIG_OF_ADDRESS is not defined for
sparc so we get the build failure.
Yes, there is an inconsistency.
of_io_request_and_map is defined in address.c and this one is compiled
only if CONFIG_OF_ADDRESS=y
on the other side, of_io_request_and_map is declared under CONFIG_OF.
So to be consistent, it should be under CONFIG_OF_ADDRESS ifdefs.
Also, of_iomap is declared several times, under CONFIG_OF_ADDRESS and
CONFIG_OF.
Perhaps there is a reason why this is done this way.
For the best of my knowledge:
Acked-by: Daniel Lezcano
Fixes: e572f844ca66 ("clocksource/drivers/meson6: Add the COMPILE_TEST option")
Fixes: bec8c4617611 ("clocksource/drivers/mediatek: Add the COMPILE_TEST
option")
Fixes: 4a373b45f94a ("clocksource/drivers/asm9260: Add the COMPILE_TEST option")
Cc: Daniel Lezcano
Signed-off-by: Sudip Mukherjee
---
v1: had a complicated set of #ifdefs
v2: i messed up and resulted in build failure of some other arch where
CONFIG_OF is not defined.
v3: tested with allmodconfig of x86_64, defconfig of alpha and mips.
v4: changed subject and commit message. And the of_io_request_and_map()
is moved under existing #ifdef instead of defining one more section.
include/linux/of_address.h | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 507daad..4d6c50a 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -36,6 +36,8 @@ extern struct device_node *of_find_matching_node_by_address(
const struct of_device_id *matches,
u64 base_address);
extern void __iomem *of_iomap(struct device_node *device, int index);
+void __iomem *of_io_request_and_map(struct device_node *device,
+ int index, const char *name);
/* Extract an address from a device, returns the region size and
* the address space flags too. The PCI version uses a BAR number
@@ -58,6 +60,14 @@ extern int of_dma_get_range(struct device_node *np, u64
*dma_addr,
extern bool of_dma_is_coherent(struct device_node *np);
#else /* CONFIG_OF_ADDRESS */
+#include
+
+static inline void __iomem *of_io_request_and_map(struct device_node *device,
+ int index, const char *name)
+{
+ return IOMEM_ERR_PTR(-EINVAL);
+}
+
static inline u64 of_translate_address(struct device_node *np,
const __be32 *addr)
{
@@ -112,8 +122,6 @@ static inline bool of_dma_is_coherent(struct device_node
*np)
extern int of_address_to_resource(struct device_node *dev, int index,
struct resource *r);
void __iomem *of_iomap(struct device_node *node, int index);
-void __iomem *of_io_request_and_map(struct device_node *device,
- int index, const char *name);
#else
#include
@@ -128,12 +136,6 @@ static inline void __iomem *of_iomap(struct device_node
*device, int index)
{
return NULL;
}
-
-static inline void __iomem *of_io_request_and_map(struct device_node *device,
- int index, const char *name)
-{
- return IOMEM_ERR_PTR(-EINVAL);
-}
#endif
#if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_PCI)
--
Facebook |
Twitter |
