Re: [PATCH] of: match the compatible in the order set by the dts file
On Sat, Jul 20, 2013 at 06:44:39AM +0100, Grant Likely wrote:
> On Tue, 9 Jul 2013 16:10:53 +0800, Huang Shijie wrote:
> > 于 2013年07月09日 15:51, Sascha Hauer 写道:
> > > On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
> > >> 于 2013年07月09日 15:05, Sascha Hauer 写道:
> > >>> Why don't you set the matching order in the driver the way you want it
> > >>> to be, i.e.:
> > >>>
> > >>> { .compatible = "fsl,imx6q-uart", ... },
> > >>> { .compatible = "fsl,imx21-uart", ... },
> > >>> { .compatible = "fsl,imx1-uart", ... },
> > >>>
> > >> yes. i can set it like this.
> > >>
> > >> but this method looks like a ugly workaround.
> > > If a driver has different ways of supporting a single device, then
> > > putting the preferred or most feature rich on top doesn't look very ugly
> > > to me.
> > this method makes it much _coupled_ between the driver and the dts file.
> >
> > IMHO, it's an unnecessary _burden_ to the driver programmer:
> > he should puts the most feature compatible on the top.
> >
> > it's much graceful if we let the driver programmer be transparent about
> > this.
>
> Absolutely true. Applied, thanks.
I don't think this will work. The patch looks very similar to one that I
posted about a year ago (commit 107a84e "of: match by compatible
property first"). The problem it was trying to address was exactly the
same. However the patch caused regressions on SPARC and had to be
reverted in commit bc51b0c "Revert "of: match by compatible property
first"".
The revert commit quotes Rob having a fix for this, and I remember that
I pinged him about it occasionally, but I suspect that those must have
fallen through the cracks.
Grant, before applying this patch we should make sure that it doesn't
cause a regression again, so perhaps asking Meelis Roos (mentioned in
the revert commit) to test would be good. I have a strong feeling that
this patch will break in the same way than mine did a year ago, because
it looks too similar and doesn't handle the compatible & name
combination that Rob mentioned.
Thierry
pgpRufi8vorfn.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote: > On Sat, 20 Jul 2013, Greg KH wrote: > > > > >>That should be passed using platform data. > > > > > > > >Ick, don't pass strings around, pass pointers. If you have platform > > > >data you can get to, then put the pointer there, don't use a "name". > > > > > > I don't think I understood you here :-s We wont have phy pointer > > > when we create the device for the controller no?(it'll be done in > > > board file). Probably I'm missing something. > > > > Why will you not have that pointer? You can't rely on the "name" as the > > device id will not match up, so you should be able to rely on the > > pointer being in the structure that the board sets up, right? > > > > Don't use names, especially as ids can, and will, change, that is going > > to cause big problems. Use pointers, this is C, we are supposed to be > > doing that :) > > Kishon, I think what Greg means is this: The name you are using must > be stored somewhere in a data structure constructed by the board file, > right? Or at least, associated with some data structure somehow. > Otherwise the platform code wouldn't know which PHY hardware > corresponded to a particular name. > > Greg's suggestion is that you store the address of that data structure > in the platform data instead of storing the name string. Have the > consumer pass the data structure's address when it calls phy_create, > instead of passing the name. Then you don't have to worry about two > PHYs accidentally ending up with the same name or any other similar > problems. Close, but the issue is that whatever returns from phy_create() should then be used, no need to call any "find" functions, as you can just use the pointer that phy_create() returns. Much like all other class api functions in the kernel work. thanks, greg k-h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Sat, 20 Jul 2013, Greg KH wrote: > > >>That should be passed using platform data. > > > > > >Ick, don't pass strings around, pass pointers. If you have platform > > >data you can get to, then put the pointer there, don't use a "name". > > > > I don't think I understood you here :-s We wont have phy pointer > > when we create the device for the controller no?(it'll be done in > > board file). Probably I'm missing something. > > Why will you not have that pointer? You can't rely on the "name" as the > device id will not match up, so you should be able to rely on the > pointer being in the structure that the board sets up, right? > > Don't use names, especially as ids can, and will, change, that is going > to cause big problems. Use pointers, this is C, we are supposed to be > doing that :) Kishon, I think what Greg means is this: The name you are using must be stored somewhere in a data structure constructed by the board file, right? Or at least, associated with some data structure somehow. Otherwise the platform code wouldn't know which PHY hardware corresponded to a particular name. Greg's suggestion is that you store the address of that data structure in the platform data instead of storing the name string. Have the consumer pass the data structure's address when it calls phy_create, instead of passing the name. Then you don't have to worry about two PHYs accidentally ending up with the same name or any other similar problems. Alan Stern ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership
On Sat, 2013-07-20 at 17:17 -0700, Olof Johansson wrote: > On Fri, Jul 19, 2013 at 8:19 PM, Grant Likely wrote: > > Device tree bindings require a lot more attention than they used to. > > We've got a group of volunteers willing to take over maintaining > > bindings. This patch adds them to the MAINTAINERS file. [] > > diff --git a/MAINTAINERS b/MAINTAINERS [] > > +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS [] > > +F: arch/*/ [] > This seems a bit broad. Yep, that's every file anywhere under arch. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership
On Fri, Jul 19, 2013 at 8:19 PM, Grant Likely wrote: > Device tree bindings require a lot more attention than they used to. > We've got a group of volunteers willing to take over maintaining > bindings. This patch adds them to the MAINTAINERS file. > > This group still needs to work out a process for maintainership and how > they are going to work together. I recommend that they set up a shared > tree on git.kernel.org that they each have commit access to similar to > the tip tree or the arm-soc tree, but it is up to them. > > Signed-off-by: Grant Likely > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Stephen Warren > Cc: Ian Campbell > Cc: Rob Herring > Cc: Olof Johansson > Cc: devicetree-discuss@lists.ozlabs.org > Cc: devicet...@vger.kernel.org > --- > MAINTAINERS | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index bc286e4..12c95d5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6050,13 +6050,24 @@ L: devicet...@vger.kernel.org > W: http://fdt.secretlab.ca > T: git git://git.secretlab.ca/git/linux-2.6.git > S: Maintained > -F: Documentation/devicetree > F: drivers/of > F: include/linux/of*.h > F: scripts/dtc > K: of_get_property > K: of_match_table > > +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS > +M: Pawel Moll > +M: Mark Rutland > +M: Stephen Warren > +M: Ian Campbell > +L: devicet...@vger.kernel.org > +S: Maintained > +F: Documentation/devicetree > +F: arch/*/boot/dts > +F: arch/*/ This seems a bit broad. Someone is going to get a whole lot of email if this goes in, and it might confuse contributors on who is maintainer of what under arch. -Olof ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Sat, Jul 20, 2013 at 08:49:32AM +0530, Kishon Vijay Abraham I wrote: > Hi, > > On Saturday 20 July 2013 05:20 AM, Greg KH wrote: > >On Fri, Jul 19, 2013 at 12:06:01PM +0530, Kishon Vijay Abraham I wrote: > >>Hi, > >> > >>On Friday 19 July 2013 11:59 AM, Greg KH wrote: > >>>On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote: > Hi, > > On Friday 19 July 2013 11:13 AM, Greg KH wrote: > >On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote: > >>+ ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id); > > > >Your naming is odd, no "phy" anywhere in it? You rely on the sender > >to > >never send a duplicate name.id pair? Why not create your own ids > >based > >on the number of phys in the system, like almost all other classes > >and > >subsystems do? > > hmm.. some PHY drivers use the id they provide to perform some of > their > internal operation as in [1] (This is used only if a single PHY > provider > implements multiple PHYS). Probably I'll add an option like > PLATFORM_DEVID_AUTO > to give the PHY drivers an option to use auto id. > > [1] -> > http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html > >>> > >>>No, who cares about the id? No one outside of the phy core ever > >>>should, > >>>because you pass back the only pointer that they really do care about, > >>>if they need to do anything with the device. Use that, and then you > >>>can > >> > >>hmm.. ok. > >> > >>>rip out all of the "search for a phy by a string" logic, as that's not > >> > >>Actually this is needed for non-dt boot case. In the case of dt boot, > >>we use a > >>phandle by which the controller can get a reference to the phy. But in > >>the case > >>of non-dt boot, the controller can get a reference to the phy only by > >>label. > > > >I don't understand. They registered the phy, and got back a pointer to > >it. Why can't they save it in their local structure to use it again > >later if needed? They should never have to "ask" for the device, as the > > One is a *PHY provider* driver which is a driver for some PHY device. > This will > use phy_create to create the phy. > The other is a *PHY consumer* driver which might be any controller driver > (can > be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference > to the > phy (by *phandle* in the case of dt boot and *label* in the case of > non-dt boot). > >device id might be unknown if there are multiple devices in the system. > > I agree with you on the device id part. That need not be known to the PHY > driver. > >>> > >>>How does a consumer know which "label" to use in a non-dt system if > >>>there are multiple PHYs in the system? > >> > >>That should be passed using platform data. > > > >Ick, don't pass strings around, pass pointers. If you have platform > >data you can get to, then put the pointer there, don't use a "name". > > I don't think I understood you here :-s We wont have phy pointer > when we create the device for the controller no?(it'll be done in > board file). Probably I'm missing something. Why will you not have that pointer? You can't rely on the "name" as the device id will not match up, so you should be able to rely on the pointer being in the structure that the board sets up, right? Don't use names, especially as ids can, and will, change, that is going to cause big problems. Use pointers, this is C, we are supposed to be doing that :) thanks, greg k-h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] gpio-rcar: Add interrupt controller support to the DT bindings
On Thu, Jul 4, 2013 at 7:44 PM, Laurent Pinchart wrote: > Update the DT bindings documentation with the interrupt-controller > and #interrupt-cells properties. > > Signed-off-by: Laurent Pinchart Usually I should have an ACK from some DT person (they are on devicet...@vger.kernel.org nowadays) but this one is so straight forward that I just applied it. But they may instead protest :-) Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] mfd: add LP3943 MFD driver
On Tue, Jul 16, 2013 at 4:38 AM, Kim, Milo wrote:
This needs to be reviewed by the devicetree people.
Please break out the bindings separately and include
devicet...@vger.kernel.org on that review.
> +++ b/Documentation/devicetree/bindings/mfd/lp3943.txt
> @@ -0,0 +1,23 @@
> +Bindings for TI/National Semiconductor LP3943 Driver
> +
> +Required properties:
> + - compatible: "ti,lp3943"
> + - reg: 7bit I2C slave address. 0x60 ~ 0x67
> +
> +Optional properties:
> + - ti,pwm0, ti,pwm1: Output channel definition for PWM port 0 and 1
> + 0 = invalid, 1 = LED0, 2 = LED 1, ... 16 = LED15
> +
> +Datasheet
> + http://www.ti.com/lit/ds/snvs256b/snvs256b.pdf
> +
> +Application note: How to use LP3943 as a GPIO expander and PWM generator
> + http://www.ti.com/lit/an/snva287a/snva287a.pdf
Do we usually put these things into bindings?
> +Example:
> +
> + lp3943@60 {
> + compatible = "ti,lp3943";
> + reg = <0x60>;
> + pwm1 = /bits/ 8 <2>;/* use LED1 output as PWM #1 */
> + };
OK so there is a way to state which lines are used for PWM.
I think you should also specify which lines are used for GPIO,
and which lines are used for LEDs.
And I'd like the masks to be passed to each subdriver, so we
can avoid the scenario where one and the same line gets
used for GPIO, LED and PWM at the same time.
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
> The patchset works only for Armada 370 and Armada XP SoC, not for Kirkwood. > For some reason I was completely sure there wasn't any DT-enabled Kirkwood > boards with PCIe support. I had a quick look at Dove and Orion5x. It looks like there are none with PCIe support. So only Kirkwood is broken. Andrew ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: New device tree mailing list
On Sat, Jul 20, 2013 at 6:00 PM, Hank Leininger wrote: > On Sat, Jul 20, 2013 at 06:28:19PM +0200, Linus Walleij wrote: >> Hi MARC list archive folks, >> >> could you please start archiving the following recently addes VGER lists >> at marc.info: >> >> These go into the "Linux" folder: >> linux-gpio: http://vger.kernel.org/vger-lists.html#linux-gpio >> linux-spi: http://vger.kernel.org/vger-lists.html#linux-spi >> >> This one goes into "Development" or "Misc" I guess: >> devicetree: http://vger.kernel.org/vger-lists.html#devicetree > > Sure, I've just subscribed us to all three. They'll show in 'Misc' once > some traffic comes in, and then I'll (have to remember to) move them. > > I realize MARC didn't carry the old/original devicetree-discuss list at > ozlabs. I'm pulling down the archives from that list now. Should I > import them as 'devicetree-discuss' (historically accurate) or as > 'devicetree' (so they will appear seamless in MARC w/the new vger list's > traffic)? As long as it doesn't cause any problems with duplicate messages for the next short little while, I would merge the two archives. Thanks Hank. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 5/5] iio: mxs-lradc: add write_raw function to modify scale
Dear Jonathan Cameron, > On 07/19/2013 05:22 PM, Hector Palacios wrote: > > Dear Marek, > > > > On 07/19/2013 06:17 PM, Marek Vasut wrote: > >>> Here you have three entries per channel: > >>> in_voltageX_raw-> the sample raw value > >>> in_voltageX_scale-> the scale to multiply the raw value to get the > >> > >> voltage > >> > >>> in mV in_voltageX_scale_available -> lists the available scales of the > >>> channel > >>> > >>> For example for channel 0: > >>> > >>> # cat in_voltage0_scale_available > >>> 0.451660156 0.903320312(two scales available, first with divider by > >>> two disabled, second with divider by two enabled) > >>> > >>> # cat in_voltage0_scale > >>> 0.451660156(divider by two is currently disabled) > >>> > >>> # cat in_voltage0_raw(shows measured value) > >>> 1000 > >>> > >>> If you multiply the value by the scale you get: 1000 * 0.451660156 = > >>> 451.6 mV > >>> > >>> # echo 0.903320312 > in_voltage0_scale(enables the divider by two) > >> > >> Ok, so I have to remember this value : '0.903320312' in case I want to > >> enable divide-by-two functionality? > > > > No you don't. That's why there is a 'in_voltage_scale_available' that > > lists the available values. > > > >> H ... why would this interface not work: > >> echo 2 > in_voltage0_scale > >> > >> or > >> > >> echo 1 > in_voltage0_scale > > > > An easy thing like that is what I first submitted, but it was rejected > > and I was told to use the scale_available descriptor instead, which is > > the common interface the rest of drivers use. > > This comes down to allowing us to have one generic predictable interface > (which sometimes ends up looking uggly!). The key thing is that if you > are outputing using the _raw sysfs interfaces, the aim is to avoid doing > nasty maths in kernel to get to 'standard' units such as mV. OK, understood. > Hence that scale attribute tells you what to apply to the value. If you > just wanted it to be 1 or 2 then the in_voltage0_raw value would have to > be a long and nasty decimal. Now we do have the option of > in_voltage0_calibscale which would be applied internally to the value but > it really isn't for this purpose (it's for devices with a 'trim' control) > and you'd still have scale set to 0.903320312 or similar. Although they > have meaning obviously, in this case 1 and 2 are little more than 'magic' > numbers. > > Note that when things are quite, I'm at least in theory working on a > cleaner interface for these 'available' attributes that would also provide > in kernel access for IIO consumers. Basically this will be another > callback to get either the 'range' of pseudo continuous variables or the > 'available' set for parameters like this. Thanks for the explanation! > Being lazy I'm happy to let someone else clean this corner up if they like? > *looks hopeful* Please don't look at me, I already am fully loaded with fixing my mess all around ;-/ Best regards, Marek Vasut ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
Andrew, On Sat, Jul 20, 2013 at 07:38:47PM +0200, Andrew Lunn wrote: > On Sat, Jul 20, 2013 at 06:58:55PM +0200, Andrew Lunn wrote: > > On Mon, Jul 15, 2013 at 11:57:29AM -0300, Ezequiel Garcia wrote: > > > Here's the new MBus DT binding, implementing the changes proposed > > > by Thomas when we discussed the previous patchset: > > > > > > http://www.spinics.net/lists/arm-kernel/msg257170.html > > > > > > As far as I know, this round fixes *all* the concerns raised in the past > > > and therefore I'd like to get Acked-by's from all the parties involved > > > on the respective patches, and particularly for the DT binding. > > > > > > If there's anything left to review, we'll be glad to fix it quickly, > > > so don't hesitate in providing your feedback! > > > > > > I'm sure many of you are dying to test this new MBus thing, so to make > > > it easier for those courageous enough, I've pushed a public branch: > > > > > > > > > https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v7 > > > > I just tried this in my Kirkwood QNAP. > > > > Uncompressing Linux... done, booting the kernel. > > Booting Linux on physical CPU 0x0 > > Linux version 3.11.0-rc1-00022-g44e8c39 (l...@londo.lunn.ch) (gcc version > > 4.3.43 > > CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 > > CPU: VIVT data cache, VIVT instruction cache > > Machine: Marvell Kirkwood (Flattened Device Tree), model: QNAP TS219 family > > bootconsole [earlycon0] enabled > > Memory policy: ECC disabled, Data cache writeback > > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 > > Kernel command line: root=/dev/sda2 console=ttyS0,115200 earlyprintk > > PID hash table entries: 2048 (order: 1, 8192 bytes) > > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) > > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) > > Memory: 513268K/524288K available (4247K kernel code, 241K rwdata, 1148K > > rodata) > > Virtual kernel memory layout: > > vector : 0x - 0x1000 ( 4 kB) > > fixmap : 0xfff0 - 0xfffe ( 896 kB) > > vmalloc : 0xe080 - 0xff00 ( 488 MB) > > lowmem : 0xc000 - 0xe000 ( 512 MB) > > modules : 0xbf00 - 0xc000 ( 16 MB) > > .text : 0xc0008000 - 0xc054d050 (5397 kB) > > .init : 0xc054e000 - 0xc0576520 ( 162 kB) > > .data : 0xc0578000 - 0xc05b4420 ( 242 kB) > >.bss : 0xc05b4420 - 0xc064e104 ( 616 kB) > > SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > > Preemptible hierarchical RCU implementation. > > NR_IRQS:114 > > sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms > > Console: colour dummy device 80x30 > > Calibrating delay loop... 1587.60 BogoMIPS (lpj=7938048) > > pid_max: default: 32768 minimum: 301 > > Mount-cache hash table entries: 512 > > CPU: Testing write buffer coherency: ok > > Setting up static identity map for 0xc040e888 - 0xc040e8c4 > > pinctrl core: initialized pinctrl subsystem > > regulator-dummy: no parameters > > NET: Registered protocol family 16 > > DMA: preallocated 256 KiB pool for atomic coherent allocations > > Kirkwood: MV88F6282-Rev-A0, TCLK=2. > > Feroceon L2: Enabling L2 > > Feroceon L2: Cache support initialised. > > bio: create slab at 0 [...] > > mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window > > mvebu-pcie pcie-controller.1: PCIe1.0: cannot get tgt/attr for mem window [...] > > Any ideas? > The patchset works only for Armada 370 and Armada XP SoC, not for Kirkwood. For some reason I was completely sure there wasn't any DT-enabled Kirkwood boards with PCIe support. I apologize for not noticing this before! My plan was to get this patchset acked/merged and then add MBus DT to Kirkwood. The reason for this is that it's a simple change, but probably *very* intrusive on the DTS files. Of course, this plan was based on the assumption that the wasn't breaking anything. However, now I guess there's no other solution than adding Kirkwood to the patchset. So unless anyone has any better idea, I'll be sending a v8. Thanks again for the test! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
Andrew, On Sat, Jul 20, 2013 at 07:38:47PM +0200, Andrew Lunn wrote: > On Sat, Jul 20, 2013 at 06:58:55PM +0200, Andrew Lunn wrote: > > On Mon, Jul 15, 2013 at 11:57:29AM -0300, Ezequiel Garcia wrote: > > > Here's the new MBus DT binding, implementing the changes proposed > > > by Thomas when we discussed the previous patchset: > > > > > > http://www.spinics.net/lists/arm-kernel/msg257170.html > > > > > > As far as I know, this round fixes *all* the concerns raised in the past > > > and therefore I'd like to get Acked-by's from all the parties involved > > > on the respective patches, and particularly for the DT binding. > > > > > > If there's anything left to review, we'll be glad to fix it quickly, > > > so don't hesitate in providing your feedback! > > > > > > I'm sure many of you are dying to test this new MBus thing, so to make > > > it easier for those courageous enough, I've pushed a public branch: > > > > > > > > > https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v7 > > > > Hi Ezequiel > > > > I just tried this in my Kirkwood QNAP. > > > > Uncompressing Linux... done, booting the kernel. > > Booting Linux on physical CPU 0x0 > > Linux version 3.11.0-rc1-00022-g44e8c39 (l...@londo.lunn.ch) (gcc version > > 4.3.43 > > CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 > > CPU: VIVT data cache, VIVT instruction cache > > Machine: Marvell Kirkwood (Flattened Device Tree), model: QNAP TS219 family > > bootconsole [earlycon0] enabled > > Memory policy: ECC disabled, Data cache writeback > > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 > > Kernel command line: root=/dev/sda2 console=ttyS0,115200 earlyprintk > > PID hash table entries: 2048 (order: 1, 8192 bytes) > > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) > > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) > > Memory: 513268K/524288K available (4247K kernel code, 241K rwdata, 1148K > > rodata) > > Virtual kernel memory layout: > > vector : 0x - 0x1000 ( 4 kB) > > fixmap : 0xfff0 - 0xfffe ( 896 kB) > > vmalloc : 0xe080 - 0xff00 ( 488 MB) > > lowmem : 0xc000 - 0xe000 ( 512 MB) > > modules : 0xbf00 - 0xc000 ( 16 MB) > > .text : 0xc0008000 - 0xc054d050 (5397 kB) > > .init : 0xc054e000 - 0xc0576520 ( 162 kB) > > .data : 0xc0578000 - 0xc05b4420 ( 242 kB) > >.bss : 0xc05b4420 - 0xc064e104 ( 616 kB) > > SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > > Preemptible hierarchical RCU implementation. > > NR_IRQS:114 > > sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms > > Console: colour dummy device 80x30 > > Calibrating delay loop... 1587.60 BogoMIPS (lpj=7938048) > > pid_max: default: 32768 minimum: 301 > > Mount-cache hash table entries: 512 > > CPU: Testing write buffer coherency: ok > > Setting up static identity map for 0xc040e888 - 0xc040e8c4 > > pinctrl core: initialized pinctrl subsystem > > regulator-dummy: no parameters > > NET: Registered protocol family 16 > > DMA: preallocated 256 KiB pool for atomic coherent allocations > > Kirkwood: MV88F6282-Rev-A0, TCLK=2. > > Feroceon L2: Enabling L2 > > Feroceon L2: Cache support initialised. > > bio: create slab at 0 > > mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window > > mvebu-pcie pcie-controller.1: PCIe1.0: cannot get tgt/attr for mem window > > Hi Ezequiel > > I just put some debug into mvebu_get_tgt_attr(): > > slot 0, PCI_SLOT(devfn) 1 > type 512, rtype 512 > slot 0, PCI_SLOT(devfn) 1 > type 512, rtype 512 > slot 0, PCI_SLOT(devfn) 1 > type 512, rtype 512 > slot 0, PCI_SLOT(devfn) 1 > type 512, rtype 256 > mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window -2 > slot 0, PCI_SLOT(devfn) 2 > type 512, rtype 512 > slot 0, PCI_SLOT(devfn) 2 > type 512, rtype 512 > slot 0, PCI_SLOT(devfn) 2 > type 512, rtype 512 > slot 0, PCI_SLOT(devfn) 2 > type 512, rtype 256 > > Any ideas? > Thanks a lot for testing this! I'll take a look and let you know... -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
On Sat, Jul 20, 2013 at 06:58:55PM +0200, Andrew Lunn wrote: > On Mon, Jul 15, 2013 at 11:57:29AM -0300, Ezequiel Garcia wrote: > > Here's the new MBus DT binding, implementing the changes proposed > > by Thomas when we discussed the previous patchset: > > > > http://www.spinics.net/lists/arm-kernel/msg257170.html > > > > As far as I know, this round fixes *all* the concerns raised in the past > > and therefore I'd like to get Acked-by's from all the parties involved > > on the respective patches, and particularly for the DT binding. > > > > If there's anything left to review, we'll be glad to fix it quickly, > > so don't hesitate in providing your feedback! > > > > I'm sure many of you are dying to test this new MBus thing, so to make > > it easier for those courageous enough, I've pushed a public branch: > > > > > > https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v7 > > Hi Ezequiel > > I just tried this in my Kirkwood QNAP. > > Uncompressing Linux... done, booting the kernel. > Booting Linux on physical CPU 0x0 > Linux version 3.11.0-rc1-00022-g44e8c39 (l...@londo.lunn.ch) (gcc version > 4.3.43 > CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 > CPU: VIVT data cache, VIVT instruction cache > Machine: Marvell Kirkwood (Flattened Device Tree), model: QNAP TS219 family > bootconsole [earlycon0] enabled > Memory policy: ECC disabled, Data cache writeback > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 > Kernel command line: root=/dev/sda2 console=ttyS0,115200 earlyprintk > PID hash table entries: 2048 (order: 1, 8192 bytes) > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) > Memory: 513268K/524288K available (4247K kernel code, 241K rwdata, 1148K > rodata) > Virtual kernel memory layout: > vector : 0x - 0x1000 ( 4 kB) > fixmap : 0xfff0 - 0xfffe ( 896 kB) > vmalloc : 0xe080 - 0xff00 ( 488 MB) > lowmem : 0xc000 - 0xe000 ( 512 MB) > modules : 0xbf00 - 0xc000 ( 16 MB) > .text : 0xc0008000 - 0xc054d050 (5397 kB) > .init : 0xc054e000 - 0xc0576520 ( 162 kB) > .data : 0xc0578000 - 0xc05b4420 ( 242 kB) >.bss : 0xc05b4420 - 0xc064e104 ( 616 kB) > SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > Preemptible hierarchical RCU implementation. > NR_IRQS:114 > sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms > Console: colour dummy device 80x30 > Calibrating delay loop... 1587.60 BogoMIPS (lpj=7938048) > pid_max: default: 32768 minimum: 301 > Mount-cache hash table entries: 512 > CPU: Testing write buffer coherency: ok > Setting up static identity map for 0xc040e888 - 0xc040e8c4 > pinctrl core: initialized pinctrl subsystem > regulator-dummy: no parameters > NET: Registered protocol family 16 > DMA: preallocated 256 KiB pool for atomic coherent allocations > Kirkwood: MV88F6282-Rev-A0, TCLK=2. > Feroceon L2: Enabling L2 > Feroceon L2: Cache support initialised. > bio: create slab at 0 > mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window > mvebu-pcie pcie-controller.1: PCIe1.0: cannot get tgt/attr for mem window Hi Ezequiel I just put some debug into mvebu_get_tgt_attr(): slot 0, PCI_SLOT(devfn) 1 type 512, rtype 512 slot 0, PCI_SLOT(devfn) 1 type 512, rtype 512 slot 0, PCI_SLOT(devfn) 1 type 512, rtype 512 slot 0, PCI_SLOT(devfn) 1 type 512, rtype 256 mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window -2 slot 0, PCI_SLOT(devfn) 2 type 512, rtype 512 slot 0, PCI_SLOT(devfn) 2 type 512, rtype 512 slot 0, PCI_SLOT(devfn) 2 type 512, rtype 512 slot 0, PCI_SLOT(devfn) 2 type 512, rtype 256 Any ideas? Thanks Andrew ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 2/3] gpio-tz1090-pdc: add TZ1090 PDC gpio driver
On Tue, Jun 25, 2013 at 4:27 PM, James Hogan wrote: > Add a GPIO driver for the low-power Powerdown Controller GPIOs in the > TZ1090 SoC. > > The driver is instantiated by device tree and supports interrupts for > the SysWake GPIOs only. > > Signed-off-by: James Hogan > Cc: Grant Likely > Cc: Rob Herring > Cc: Rob Landley > Cc: Linus Walleij > Cc: linux-...@vger.kernel.org > Cc: devicetree-discuss@lists.ozlabs.org > --- > Changes in v4: Patch applied. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 1/3] gpio-tz1090: add TZ1090 gpio driver
On Tue, Jun 25, 2013 at 4:27 PM, James Hogan wrote: > Add a GPIO driver for the main GPIOs found in the TZ1090 (Comet) SoC. > This doesn't include low-power GPIOs as they're controlled separately > via the Powerdown Controller (PDC) registers. > > The driver is instantiated by device tree and supports interrupts for > all GPIOs. > > Signed-off-by: James Hogan > Cc: Grant Likely > Cc: Rob Herring > Cc: Rob Landley > Cc: Linus Walleij > Cc: linux-...@vger.kernel.org > Cc: devicetree-discuss@lists.ozlabs.org > --- > Changes in v4: Patch applied now. It is better to not stress things and queue this for v3.12 now that the pinctrl portions are in for v3.11. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
On Mon, Jul 15, 2013 at 11:57:29AM -0300, Ezequiel Garcia wrote: > Here's the new MBus DT binding, implementing the changes proposed > by Thomas when we discussed the previous patchset: > > http://www.spinics.net/lists/arm-kernel/msg257170.html > > As far as I know, this round fixes *all* the concerns raised in the past > and therefore I'd like to get Acked-by's from all the parties involved > on the respective patches, and particularly for the DT binding. > > If there's anything left to review, we'll be glad to fix it quickly, > so don't hesitate in providing your feedback! > > I'm sure many of you are dying to test this new MBus thing, so to make > it easier for those courageous enough, I've pushed a public branch: > > > https://github.com/MISL-EBU-System-SW/mainline-public/tree/marvell-mvebu-mbus-v7 Hi Ezequiel I just tried this in my Kirkwood QNAP. Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0x0 Linux version 3.11.0-rc1-00022-g44e8c39 (l...@londo.lunn.ch) (gcc version 4.3.43 CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 CPU: VIVT data cache, VIVT instruction cache Machine: Marvell Kirkwood (Flattened Device Tree), model: QNAP TS219 family bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: root=/dev/sda2 console=ttyS0,115200 earlyprintk PID hash table entries: 2048 (order: 1, 8192 bytes) Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 513268K/524288K available (4247K kernel code, 241K rwdata, 1148K rodata) Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xe080 - 0xff00 ( 488 MB) lowmem : 0xc000 - 0xe000 ( 512 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .text : 0xc0008000 - 0xc054d050 (5397 kB) .init : 0xc054e000 - 0xc0576520 ( 162 kB) .data : 0xc0578000 - 0xc05b4420 ( 242 kB) .bss : 0xc05b4420 - 0xc064e104 ( 616 kB) SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Preemptible hierarchical RCU implementation. NR_IRQS:114 sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms Console: colour dummy device 80x30 Calibrating delay loop... 1587.60 BogoMIPS (lpj=7938048) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0xc040e888 - 0xc040e8c4 pinctrl core: initialized pinctrl subsystem regulator-dummy: no parameters NET: Registered protocol family 16 DMA: preallocated 256 KiB pool for atomic coherent allocations Kirkwood: MV88F6282-Rev-A0, TCLK=2. Feroceon L2: Enabling L2 Feroceon L2: Cache support initialised. bio: create slab at 0 mvebu-pcie pcie-controller.1: PCIe0.0: cannot get tgt/attr for mem window mvebu-pcie pcie-controller.1: PCIe1.0: cannot get tgt/attr for mem window Unable to handle kernel paging request at virtual address 1804 pgd = c0004000 [1804] *pgd= Internal error: Oops: 805 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.11.0-rc1-00022-g44e8c39 #35 task: df848000 ti: df84a000 task.ti: df84a000 PC is at mvebu_pcie_setup+0x84/0x2b4 LR is at mvebu_pcie_setup+0x74/0x2b4 pc : []lr : []psr: 2053 sp : df84bd70 ip : fp : r10: r9 : c06435f4 r8 : df84be0c r7 : r6 : df8359d0 r5 : df9e8410 r4 : df9e7180 r3 : 1804 r2 : r1 : ffe0 r0 : c06435f4 Flags: nzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 0005397f Table: 4000 DAC: 0017 Process swapper (pid: 1, stack limit = 0xdf84a1b8) Stack: (0xdf84bd70 to 0xdf84c000) bd60: df801e00 df8f8a10 df9e7180 bd80: df9e71a0 df8f8a00 df84be0c df84bdb0 c000d438 bda0: 0018 c0206e58 c04db1d8 df84bdb0 df84bdb0 df9e8410 df9e8410 bdc0: df8359d0 df8f8a00 df8f8a10 c0c89170 df9e8410 c0561f98 bde0: df9e842c df911fa0 a1ff 7846 11ab 0604 df84be0c be00: c059615c 0001 df84be34 c0562260 c01d3468 be20: c0562230 c01d2b88 df8359d0 df8f8a10 be40: df8f8a10 c059611c c0646070 c054e380 c05b4434 c020bdd8 be60: c020ac28 df8f8a10 df8f8a44 c059611c c020adb8 c0561d0c c020ae44 be80: df84be90 c059611c c02093f8 df80de8c df8f9e10 df9e72d4 df804b00 bea0: df9e72a0 c059611c c059dc50 c0209c3c c04d7b78 c01cf608 c0596108 c0596108 bec0: c059611c 0005 009c c020b208 c0596108 c056f73c 0005 bee0: 009c c020c0e8 c05760f8 c056f73c 0005 c0008684 c0411b70 c0638b64 bf00: 003f 6053 bf20
Re: New device tree mailing list
Hi MARC list archive folks, could you please start archiving the following recently addes VGER lists at marc.info: These go into the "Linux" folder: linux-gpio: http://vger.kernel.org/vger-lists.html#linux-gpio linux-spi: http://vger.kernel.org/vger-lists.html#linux-spi This one goes into "Development" or "Misc" I guess: devicetree: http://vger.kernel.org/vger-lists.html#devicetree All are important for embedded Linux developers in particular, as can be seen per below. On Sat, Jul 20, 2013 at 3:29 AM, Joe Perches wrote: > On Fri, 2013-07-19 at 18:23 -0700, Grant Likely wrote: >> The ozlabs devicetree list was requiring too much work to moderate, so >> I'm closing down that list and replacing it with a list on >> vger.kernel.org. >> >> http://vger.kernel.org/vger-lists.html#devicetree > > Hey Grant. > > Can you also please setup an email archive? > Something like gmane or equivalent. Thanks for your awesome archives! Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] MAINTAINERS: Refactor device tree maintainership
On Sat, Jul 20, 2013 at 5:19 AM, Grant Likely wrote: > Device tree bindings require a lot more attention than they used to. > We've got a group of volunteers willing to take over maintaining > bindings. This patch adds them to the MAINTAINERS file. > > This group still needs to work out a process for maintainership and how > they are going to work together. I recommend that they set up a shared > tree on git.kernel.org that they each have commit access to similar to > the tip tree or the arm-soc tree, but it is up to them. > > Signed-off-by: Grant Likely > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Stephen Warren > Cc: Ian Campbell > Cc: Rob Herring > Cc: Olof Johansson > Cc: devicetree-discuss@lists.ozlabs.org > Cc: devicet...@vger.kernel.org Excellent move. Acked-by: Linus Walleij Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [Ksummit-2013-discuss] [ATTEND] Handling of devicetree bindings
On Mon, Jul 15, 2013 at 8:50 PM, David Woodhouse wrote: > I've heard tales of people having to keep device-tree files for their > board tightly in sync with the specific *version* of the Linux kernel > that they were shipped with. > > That makes me very sad, because it almost certainly means that someone > has done it completely and utterly wrong. This paradigm creep up in ideas like the FIT image at this years ELC: http://events.linuxfoundation.org/images/stories/slides/elc2013_fernandes.pdf Surely, most complex mobile systems (such as mobile handsets) are flashed with some custom-brew composite images, FIT seems to want to start to standardize that. However the dangerous stuff is not this tool even, it happens on the build systems: multiple things are compiled together and stuffed into an image, the device tree and kernel is always recompiled at every image composition. Everything is versioned in sync. This means that most embedded companies have a build system where it is possible for system integrators to alter kernel code and device trees at the same time. I think their mental model is that of assembling a fridge or a car or something - you take this bolt and it fits with that nut, and it's OK if it only fits on just this one model of the end product. Changing that way of thinking goes well outside the kernel community I'm afraid, one way would be if device trees had conformance tests such as is done for ACPI (or USB, or whatever) meaning it will at some point arrive at a final, definitive form, and you're not allowed to alter bindings etc at that point. And given all bindings are available this can be done early on in the hardware projects. I think a group of volunteers are up to move in this direction. Needless to say, doing it the slow way threatens to slow down the deployment phase and lead to Gantt-effects in projects. Which I guess is why these companies really like the idea of tying in the device tree with the kernel. Or to put it another way: I think this is caused by embedded companies constantly having one finger pressing the fast-forward button. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH v7 00/22] MBus DT binding: The return of PCIe
Hi Grant, Arnd, Jason: On Mon, Jul 15, 2013 at 11:57:29AM -0300, Ezequiel Garcia wrote: > Here's the new MBus DT binding, implementing the changes proposed > by Thomas when we discussed the previous patchset: > > http://www.spinics.net/lists/arm-kernel/msg257170.html > > As far as I know, this round fixes *all* the concerns raised in the past > and therefore I'd like to get Acked-by's from all the parties involved > on the respective patches, and particularly for the DT binding. > > If there's anything left to review, we'll be glad to fix it quickly, > so don't hesitate in providing your feedback! > Can you comment on this DT binding? Notice this is the outcome of a lengthy discussion and has been already agreed by Arnd and Jason Gunthorpe. If it looks OK, I'd like to have formal Acked-by's so Jason Cooper can merge it. On the other side, given we've decided to mark some bindings as 'unstable' or 'staging' maybe Jason can merge it so it can be in linux-next. This way developers can actually start using this, and complaining if there's anything to complain. If we leave it as a patchset floating in mailing-lists it's hardly going to get tested. Does this approach make sense? Thanks a lot! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: The future of DT binding maintainership
On Saturday 20 of July 2013 04:46:47 Grant Likely wrote: > A number of us had a face-to-face meeting in Dublin last week to talk > about DT maintainership and the fact that it simply isn't working right > now. Neither Rob nor I can keep up with the load and there are a lot of > poorly designed bindings appearing in the tree. > > Device tree binding maintainership needs to be split off to a separate > group, and we've started with a few people willing to help, Pawel Moll, > Mark Rutland, Stephen Warren and Ian Campbell. > > (BTW, even though I've already sent a patch adding that group > MAINTAINERS, this is not set in stone. Anyone else wanting to help > maintain should volunteer) > > Another thing discussed is that we need to start validating DT schema > with an extension to dtc. Tomasz Figa has volunteered to do this work > and has support from his employer to spend time on it. What I'm hoping > to have is that the DT schema will get checked as part of the dts build > process so that any DT file that doesn't match the documented schema > will get flagged, and that the schema files will be human readable and > will double as documentation. > > There is not yet any process for binding maintainership. We talked about > a few ideas, but they really need to be hashed out here on the mailing > list. A couple of the questions: > > - How are bindings allowed to be merged? Through subsystem trees, or > only through the bindings tree? > - Through the bindings tree is more work but it will provide more > control. > - Through subsystem trees means drivers and bindings get merged > together. > - If we have a schema tool that reports errors on missing or > unapproved schema, then spliting the driver from the binding won't > matter that much. > - Do we need to differentiate between 'staging' and 'stable' bindings? > - What is the schedule for splitting the bindings and .dts files out of > the kernel? > - Ian Campbell is maintaining a DT bindings and .dts mirror tree which > should eventually become the 'master' for merging DT bindings. I remember getting to a conclusion that: - bindings should enter staging state after being introduced, - from time to time a binding review meeting should take place (on IRC possibly) and discuss which of introduced staging bindings are ready to enter stable state, - in stable state such binding would be considered an ABI. >From remaining questions I remember: - How should we mark bindings as staging and stable? (i.e. documentation/schema files in different folders or something else?) - Should we also split parts of dts/dtsi using staging bindings from those using stable ones? (This could mean including stable dts/dtsi file from inside unstable one, which would allow having a stable dts with basic functionality that could be extended over the time after validating staging bindings used in unstable part.) As for my part, I'm now looking into existing infrastructure inside of dtc to get some hints that would allow me to design the initial schema syntax in a most dtc-friendly way. Give me a bit more time and I will then write down everything I have and post to the ML to start a discussion. Best regards, Tomasz ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] iio: core: implement devm_iio_device_alloc/devm_iio_device_free
On 07/18/2013 12:19 PM, Oleksandr Kravchenko wrote:
From: Grygorii Strashko
Add a resource managed devm_iio_device_alloc()/devm_iio_device_free()
to automatically clean up any allocations made by IIO drivers,
thus leading to simplified IIO drivers code.
In addition, this will allow IIO drivers to use other devm_*() API
(like devm_request_irq) and don't care about the race between
iio_device_free() and the release of resources by Device core
during driver removing.
Signed-off-by: Grygorii Strashko
[o.v.kravche...@globallogic.com: fix return value ib devm_iio_device_alloc
in case if devres_alloc failed, remove unused variable "rc"]
Signed-off-by: Oleksandr Kravchenko
Tested-by: Oleksandr Kravchenko
Very nice, thanks for taking care of this.
Reviewed-by: Lars-Peter Clausen
---
drivers/iio/industrialio-core.c | 47 +++
include/linux/iio/iio.h | 25 +
2 files changed, 72 insertions(+)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index e145931..d56d122 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -912,6 +912,53 @@ void iio_device_free(struct iio_dev *dev)
}
EXPORT_SYMBOL(iio_device_free);
+static void devm_iio_device_release(struct device *dev, void *res)
+{
+ iio_device_free(*(struct iio_dev **)res);
+}
+
+static int devm_iio_device_match(struct device *dev, void *res, void *data)
+{
+ struct iio_dev **r = res;
+ if (!r || !*r) {
+ WARN_ON(!r || !*r);
+ return 0;
+ }
+ return *r == data;
+}
+
+struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv)
+{
+ struct iio_dev **ptr, *iio_dev;
+
+ ptr = devres_alloc(devm_iio_device_release, sizeof(*ptr),
+ GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ /* use raw alloc_dr for kmalloc caller tracing */
+ iio_dev = iio_device_alloc(sizeof_priv);
+ if (iio_dev) {
+ *ptr = iio_dev;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return iio_dev;
+}
+EXPORT_SYMBOL_GPL(devm_iio_device_alloc);
+
+void devm_iio_device_free(struct device *dev, struct iio_dev *iio_dev)
+{
+ int rc;
+
+ rc = devres_release(dev, devm_iio_device_release,
+ devm_iio_device_match, iio_dev);
+ WARN_ON(rc);
+}
+EXPORT_SYMBOL_GPL(devm_iio_device_free);
+
/**
* iio_chrdev_open() - chrdev file open for buffer access and ioctls
**/
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 8d171f4..f1d99f6 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -532,6 +532,31 @@ static inline struct iio_dev *iio_priv_to_dev(void *priv)
void iio_device_free(struct iio_dev *indio_dev);
/**
+ * devm_iio_device_alloc - Resource-managed iio_device_alloc()
+ * @dev: Device to allocate iio_dev for
+ * @sizeof_priv: Space to allocate for private structure.
+ *
+ * Managed iio_device_alloc. iio_dev allocated with this function is
+ * automatically freed on driver detach.
+ *
+ * If an iio_dev allocated with this function needs to be freed separately,
+ * devm_iio_device_free() must be used.
+ *
+ * RETURNS:
+ * Pointer to allocated iio_dev on success, NULL on failure.
+ */
+struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv);
+
+/**
+ * devm_iio_device_free - Resource-managed iio_device_free()
+ * @dev: Device this iio_dev belongs to
+ * @indio_dev: the iio_dev associated with the device
+ *
+ * Free indio_dev allocated with devm_iio_device_alloc().
+ */
+void devm_iio_device_free(struct device *dev, struct iio_dev *iio_dev);
+
+/**
* iio_buffer_enabled() - helper function to test if the buffer is enabled
* @indio_dev:IIO device structure for device
**/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] of: Add more stubs for non-OF builds
On Sat, 20 Jul 2013 06:31:11 +0100
Grant Likely wrote:
> On Tue, 18 Jun 2013 18:39:22 +0400, Alexander Shiyan wrote:
> > Patch adds of_get_next_child and of_get_next_available_child
> > stubs for non-OF builds.
> >
> > Signed-off-by: Alexander Shiyan
> > ---
> > include/linux/of.h | 16 ++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/of.h b/include/linux/of.h
> > index 1fd08ca..c086c1a 100644
> > --- a/include/linux/of.h
> > +++ b/include/linux/of.h
> > @@ -366,8 +366,17 @@ static inline bool of_have_populated_dt(void)
> > return false;
> > }
> >
> > -#define for_each_child_of_node(parent, child) \
> > - while (0)
> > +static inline struct device_node *of_get_next_child(
> > + const struct device_node *node, struct device_node *prev)
> > +{
> > + return NULL;
> > +}
> > +
> > +static inline struct device_node *of_get_next_available_child(
> > + const struct device_node *node, struct device_node *prev)
> > +{
> > + return NULL;
> > +}
> >
> > static inline struct device_node *of_get_child_by_name(
> > const struct device_node *node,
> > @@ -376,6 +385,9 @@ static inline struct device_node *of_get_child_by_name(
> > return NULL;
> > }
> >
> > +#define for_each_child_of_node(parent, child) \
> > + while (0)
> > +
>
> Why is the for_each_child_of_node() getting moved?
Please forget this patch, this is no longer needed.
A move was to preserve the sort order for "OF" and "non-OF".
Thanks.
--
Alexander Shiyan
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
The future of DT binding maintainership
A number of us had a face-to-face meeting in Dublin last week to talk about DT maintainership and the fact that it simply isn't working right now. Neither Rob nor I can keep up with the load and there are a lot of poorly designed bindings appearing in the tree. Device tree binding maintainership needs to be split off to a separate group, and we've started with a few people willing to help, Pawel Moll, Mark Rutland, Stephen Warren and Ian Campbell. (BTW, even though I've already sent a patch adding that group MAINTAINERS, this is not set in stone. Anyone else wanting to help maintain should volunteer) Another thing discussed is that we need to start validating DT schema with an extension to dtc. Tomasz Figa has volunteered to do this work and has support from his employer to spend time on it. What I'm hoping to have is that the DT schema will get checked as part of the dts build process so that any DT file that doesn't match the documented schema will get flagged, and that the schema files will be human readable and will double as documentation. There is not yet any process for binding maintainership. We talked about a few ideas, but they really need to be hashed out here on the mailing list. A couple of the questions: - How are bindings allowed to be merged? Through subsystem trees, or only through the bindings tree? - Through the bindings tree is more work but it will provide more control. - Through subsystem trees means drivers and bindings get merged together. - If we have a schema tool that reports errors on missing or unapproved schema, then spliting the driver from the binding won't matter that much. - Do we need to differentiate between 'staging' and 'stable' bindings? - What is the schedule for splitting the bindings and .dts files out of the kernel? - Ian Campbell is maintaining a DT bindings and .dts mirror tree which should eventually become the 'master' for merging DT bindings. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] of: Add more stubs for non-OF builds
On Tue, 18 Jun 2013 18:39:22 +0400, Alexander Shiyan wrote:
> Patch adds of_get_next_child and of_get_next_available_child
> stubs for non-OF builds.
>
> Signed-off-by: Alexander Shiyan
> ---
> include/linux/of.h | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 1fd08ca..c086c1a 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -366,8 +366,17 @@ static inline bool of_have_populated_dt(void)
> return false;
> }
>
> -#define for_each_child_of_node(parent, child) \
> - while (0)
> +static inline struct device_node *of_get_next_child(
> + const struct device_node *node, struct device_node *prev)
> +{
> + return NULL;
> +}
> +
> +static inline struct device_node *of_get_next_available_child(
> + const struct device_node *node, struct device_node *prev)
> +{
> + return NULL;
> +}
>
> static inline struct device_node *of_get_child_by_name(
> const struct device_node *node,
> @@ -376,6 +385,9 @@ static inline struct device_node *of_get_child_by_name(
> return NULL;
> }
>
> +#define for_each_child_of_node(parent, child) \
> + while (0)
> +
Why is the for_each_child_of_node() getting moved?
g.
> static inline int of_get_child_count(const struct device_node *np)
> {
> return 0;
> --
> 1.8.1.5
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] DT: add vendor prefixes for hisilicon
On Mon, 17 Jun 2013 13:04:59 +0800, Zhangfei Gao wrote: > Signed-off-by: Zhangfei Gao Applied. g. > --- > .../devicetree/bindings/vendor-prefixes.txt|1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index 6931c43..e18f3ad 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -25,6 +25,7 @@ est ESTeem Wireless Modems > fsl Freescale Semiconductor > GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. > gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. > +hisiliconHisilicon Limited. > hp Hewlett Packard > ibm International Business Machines (IBM) > idt Integrated Device Technologies, Inc. > -- > 1.7.9.5 > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] of: Specify initrd location using 64-bit
On Mon, 01 Jul 2013 16:34:26 -0500, Rob Herring wrote: > On 07/01/2013 01:20 PM, Santosh Shilimkar wrote: > > On some PAE architectures, the entire range of physical memory could reside > > outside the 32-bit limit. These systems need the ability to specify the > > initrd location using 64-bit numbers. > > > > This patch globally modifies the early_init_dt_setup_initrd_arch() function > > to > > use 64-bit numbers instead of the current unsigned long. > > > > There has been quite a bit of debate about whether to use u64 or > > phys_addr_t. > > It was concluded to stick to u64 to be consistent with rest of the device > > tree code. As summarized by Geert, "The address to load the initrd is > > decided > > by the bootloader/user and set at that point later in time. The dtb should > > not > > be tied to the kernel you are booting" > > That was quoting me. Otherwise: > > Acked-by: Rob Herring > > Unless Grant feels compelled to pick this up for 3.11, I think it has to > wait for 3.12. Nope, 3.12 is fine. Applied. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [Ksummit-2013-discuss] [ATTEND] Handling of devicetree bindings
On Mon, 15 Jul 2013 19:50:27 +0100, David Woodhouse wrote: > On Mon, 2013-07-15 at 09:56 -0700, Greg KH wrote: > > How about a hint for subsystem maintainers as to what exactly we should > > be looking for with these bindings? I for one have no idea what is > > "right" vs. "wrong" with them, so a document explaining this would be > > good to have. > > > > Or if we already have it, a pointer to it perhaps? > > The biggest thing is that it should describe the *hardware*, in a > fashion which is completely OS-agnostic. > > The same device-tree binding should work for Solaris, *BSD, Windows, > eCos, and everything else. > > I've heard tales of people having to keep device-tree files for their > board tightly in sync with the specific *version* of the Linux kernel > that they were shipped with. > > That makes me very sad, because it almost certainly means that someone > has done it completely and utterly wrong. It is wrong, but it has happened. At first it was getting up and running with DT in ARM which was a major shift, but now it is down to lack of process. There is a new team of maintainers for DT bindings that I've just sent and email about. The ultimate goal is to add schema checking to device tree bindings and get them out of the kernel entirely. That should resolve the tightly-coupled problem that we're currently dealing with. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/3] MAINTAINERS: Change device tree mailing list
New list on vger.kernel.org. The old list was a pain to moderate. Signed-off-by: Grant Likely Cc: Rob Herring Cc: devicetree-discuss@lists.ozlabs.org Cc: devicet...@vger.kernel.org --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 844d7e8..bc286e4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5882,7 +5882,7 @@ OMAP DEVICE TREE SUPPORT M: Benoît Cousson M: Tony Lindgren L: linux-o...@vger.kernel.org -L: devicetree-discuss@lists.ozlabs.org (moderated for non-subscribers) +L: devicet...@vger.kernel.org S: Maintained F: arch/arm/boot/dts/*omap* F: arch/arm/boot/dts/*am3* @@ -6046,7 +6046,7 @@ F:drivers/i2c/busses/i2c-ocores.c OPEN FIRMWARE AND FLATTENED DEVICE TREE M: Grant Likely M: Rob Herring -L: devicetree-discuss@lists.ozlabs.org (moderated for non-subscribers) +L: devicet...@vger.kernel.org W: http://fdt.secretlab.ca T: git git://git.secretlab.ca/git/linux-2.6.git S: Maintained -- 1.8.1.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [Ksummit-2013-discuss] [ATTEND] Handling of devicetree bindings
On Mon, 15 Jul 2013 23:07:36 +0200, Linus Walleij wrote: > On Mon, Jul 15, 2013 at 4:29 PM, Jonathan Corbet wrote: > > > Do we need a kernel summit discussion, or do we just need a good > > document? Or, to phrase the question another way, are we lacking a > > consensus among the clueful regarding how device tree bindings should be > > designed, or are we simply lacking education? > > I think both. I fear some maintainers do not know enough about > the subject to know if a binding should be rejected. I think that it would make more sense to be a topic at an ARM maintainers summit with the output being a *short* guidance statement for all maintainers stating who is responsible for approving and merging new bindings. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: add vendor prefix for Qualcomm Atheros, Inc.
On Wed, 1 May 2013 10:53:54 +0200, Gabor Juhos wrote: > This prefix will be used in various compatible properties > for the devices from Qualcomm Atheros, Inc. > > Cc: Luis R. Rodriguez > Signed-off-by: Gabor Juhos Applied, thanks g. > --- > Documentation/devicetree/bindings/vendor-prefixes.txt |1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index 19e1ef7..20559cd 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -40,6 +40,7 @@ nxp NXP Semiconductors > onnn ON Semiconductor Corp. > picochip Picochip Ltd > powervr PowerVR (deprecated, use img) > +qca Qualcomm Atheros, Inc. > qcom Qualcomm, Inc. > ramtron Ramtron International > realtek Realtek Semiconductor Corp. > -- > 1.7.10 > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of/platform: Staticize of_platform_device_create_pdata()
On Mon, 1 Jul 2013 20:26:52 +0100, Mark Brown wrote: > From: Mark Brown > > It is not used outside of this file so doesn't need to be in the global > namespace. > > Signed-off-by: Mark Brown Applied, thanks. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: match the compatible in the order set by the dts file
On Tue, 9 Jul 2013 16:10:53 +0800, Huang Shijie wrote:
> äº 2013å¹´07æ09æ¥ 15:51, Sascha Hauer åé:
> > On Tue, Jul 09, 2013 at 03:46:34PM +0800, Huang Shijie wrote:
> >> äº 2013å¹´07æ09æ¥ 15:05, Sascha Hauer åé:
> >>> Why don't you set the matching order in the driver the way you want it
> >>> to be, i.e.:
> >>>
> >>> { .compatible = "fsl,imx6q-uart", ... },
> >>> { .compatible = "fsl,imx21-uart", ... },
> >>> { .compatible = "fsl,imx1-uart", ... },
> >>>
> >> yes. i can set it like this.
> >>
> >> but this method looks like a ugly workaround.
> > If a driver has different ways of supporting a single device, then
> > putting the preferred or most feature rich on top doesn't look very ugly
> > to me.
> this method makes it much _coupled_ between the driver and the dts file.
>
> IMHO, it's an unnecessary _burden_ to the driver programmer:
> he should puts the most feature compatible on the top.
>
> it's much graceful if we let the driver programmer be transparent about
> this.
Absolutely true. Applied, thanks.
g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Reusing DTSI files across trees with differing numbers of address-cells
On Fri, 26 Apr 2013 16:17:52 -0700, Stepan Moskovchenko wrote: > > Hello. I am creating a DTS file for an ARM (Qualcomm MSM) target which > supports LPAE, meaning that the target is capable of addressing memory > beyond the standard 4GB boundary. To account for the fact that the > memory node can contain reg addresses that exceed 32 bits, I am setting > #address-cells and #size-cells to 2 at the top level of my tree, since > this is what the kernel will use when parsing the memory node. > > However, my internal tree contains multiple DTSI files with definitions > for some hardware blocks that are used across multiple MSM targets, > including ones that have #address-cells and #size-cells set to 1 at the > top level, I would like to re-use some of these files in the tree for my > LPAE-based target. Additionally, most MSM I/O devices are declared at > the top level of the tree, rather than on a dedicated simple-bus. > > To allow reuse of common hardware block definitions, I am considering > moving all the MSM memory-mapped I/O devices to a dedicated /soc node > (per the Power spec), declaring this node as a simple-bus with > #address-cells and #size-cells of 1, and using the ranges property to > map this bus into the top-level address space. Since MSM I/O devices are > located at addresses below 4GB, I believe it is okay to keep them on a > simple-bus with #address-cells=1. > > Does this seem like a reasonable approach? Yes. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] OF: make of_property_for_each_{u32|string}() use parameters if OF is not enabled
On Mon, 17 Jun 2013 16:48:13 +0200, Sebastian Andrzej Siewior
wrote:
> I am getting a few
> |warning: unused variable âpâ [-Wunused-variable]
> |warning: unused variable âpropâ [-Wunused-variable]
>
> in the case where CONFIG_OF is not defined and the parameters are only
> used in the loop macro.
>
> Signed-off-by: Sebastian Andrzej Siewior
Applied, thanks
g.
> ---
>
> I also made that change for of_property_for_each_string().
>
> include/linux/of.h | 39 ---
> 1 file changed, 24 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 1fd08ca..90a8811 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -323,12 +323,6 @@ extern int of_detach_node(struct device_node *);
> */
> const __be32 *of_prop_next_u32(struct property *prop, const __be32 *cur,
> u32 *pu);
> -#define of_property_for_each_u32(np, propname, prop, p, u) \
> - for (prop = of_find_property(np, propname, NULL), \
> - p = of_prop_next_u32(prop, NULL, &u); \
> - p; \
> - p = of_prop_next_u32(prop, p, &u))
> -
> /*
> * struct property *prop;
> * const char *s;
> @@ -337,11 +331,6 @@ const __be32 *of_prop_next_u32(struct property *prop,
> const __be32 *cur,
> * printk("String value: %s\n", s);
> */
> const char *of_prop_next_string(struct property *prop, const char *cur);
> -#define of_property_for_each_string(np, propname, prop, s) \
> - for (prop = of_find_property(np, propname, NULL), \
> - s = of_prop_next_string(prop, NULL);\
> - s; \
> - s = of_prop_next_string(prop, s))
>
> #else /* CONFIG_OF */
>
> @@ -505,12 +494,20 @@ static inline int of_machine_is_compatible(const char
> *compat)
> return 0;
> }
>
> +static inline const __be32 *of_prop_next_u32(struct property *prop,
> + const __be32 *cur, u32 *pu)
> +{
> + return NULL;
> +}
> +
> +static inline const char *of_prop_next_string(struct property *prop,
> + const char *cur)
> +{
> + return NULL;
> +}
> +
> #define of_match_ptr(_ptr) NULL
> #define of_match_node(_matches, _node) NULL
> -#define of_property_for_each_u32(np, propname, prop, p, u) \
> - while (0)
> -#define of_property_for_each_string(np, propname, prop, s) \
> - while (0)
> #endif /* CONFIG_OF */
>
> #ifndef of_node_to_nid
> @@ -559,6 +556,18 @@ static inline int of_property_read_u32(const struct
> device_node *np,
> return of_property_read_u32_array(np, propname, out_value, 1);
> }
>
> +#define of_property_for_each_u32(np, propname, prop, p, u) \
> + for (prop = of_find_property(np, propname, NULL), \
> + p = of_prop_next_u32(prop, NULL, &u); \
> + p; \
> + p = of_prop_next_u32(prop, p, &u))
> +
> +#define of_property_for_each_string(np, propname, prop, s) \
> + for (prop = of_find_property(np, propname, NULL), \
> + s = of_prop_next_string(prop, NULL);\
> + s; \
> + s = of_prop_next_string(prop, s))
> +
> #if defined(CONFIG_PROC_FS) && defined(CONFIG_PROC_DEVICETREE)
> extern void proc_device_tree_add_node(struct device_node *, struct
> proc_dir_entry *);
> extern void proc_device_tree_add_prop(struct proc_dir_entry *pde, struct
> property *prop);
> --
> 1.8.3.1
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC] Driver configuration using Device Tree
On Tue, 09 Jul 2013 14:10:58 -0600, Eric Holmberg
wrote:
> I am trying to determine if Device Tree is an appropriate use for
> configuring drivers and would like to request comments. We currently
> use Device Tree in our Shared Memory Driver (SMD) that manages up to 64
> ports (where a port consists of an RX FIFO and a TX FIFO) between any
> two processors and a pair of interrupts for each processor. The shared
> memory address and interrupt configuration is stored in Device Tree and
> since this is hardware, this is considered an acceptable use. However,
> we also have two separate modules that use SMD and export devices to
> userspace through either the TTY framework (SMD TTY) or through a
> character device (SMD PKT). For these drivers, the configuration has
> less to do with hardware and more about which port to connect to in the
> SMD driver and how to expose the port to userspace through a device
> node. This code is used in Linux-based phones.
>
> The DT configuration looks like this:
> qcom,smdtty {
> compatible = "qcom,smdtty";
>
> qcom,smdtty-ds {
> qcom,smdtty-port-name = "DS";
> qcom,smdtty-edge = <0>;
> qcom,smdtty-dev-idx = <0>;
> };
> . . .
> /* on the order of 10 more port config items */
>};
>
>
> Question
>
> Is there a concern that DT should only be used for hardware
> configuration and that this "driver configuration" is not an acceptable
> use? If it is not acceptable, should I go back to using platform
> devices (seems like a step backwards) or some other method such as
> exporting a control channel to userspace that can be configured using an
> IOCTL?
It still is a reasonable leap to say that the DT contains the known-sane
configuration settings that are needed by the platform. It may not be
/strictly/ a hardware description, but it is a description of the usage
model of the platform.
I would however say that you only want that configuration to appear once
in the system. If, say, the linux host sets up and configures the SMD
regions, then I would like to see the remote systems dynamically
receiving the configuration from the linux host instead of having a
separate configuration file.
g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] PM / OPP: updates to enable sharing OPPs info
On Tue, 21 May 2013 11:00:35 +0100, Sudeep KarkadaNagesha wrote: > Hi Rob, Grant, > > On 01/05/13 12:11, Sudeep KarkadaNagesha wrote: > > From: Sudeep KarkadaNagesha > > > > These are couple of updates to existing PM/OPP library to support > > sharing of OPPs between different device nodes. > > > > Currently all the cpu nodes are parsed until the OPPs are found. This > > is essential to support cpuhotplug without having to replicate OPP > > information in all the cpu nodes. > > > > However in systems with multiple cpu power domain, its better to have > > OPP entry for each cpu. To avoid replication, phandle can be specified > > to the node which contains the full OPP information. > > > Is proposed option of phandle for OPP acceptable to avoid replication ? > Any suggestions to proceed on this ? This is needed to support CPU > hotplug on big LITTLE system where current methods like parsing all the > nodes or just CPU0 node will not work. Looks fine to me. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of/irq: init struct resource to 0 in of_irq_to_resource()
On Thu, 18 Jul 2013 21:49:27 -0500, Rob Herring wrote: > On 07/18/2013 05:24 AM, Sebastian Andrzej Siewior wrote: > > It almost does not matter because most users use only the ->start member > > of the struct. However if this struct is passed to a platform device > > which is then added via platform_device_add() then the ->parent member is > > also used. > > Most users don't use the resource struct at all. The ones that do, all > seem to do a memset beforehand. So I think current behavior is correct. > > There are some occurrences that pass a resource in, but then don't > actually use the resource. Those we should fix. It's a reasonable safeguard though. I'm going to apply it. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of/irq: Avoid calling list_first_entry() for empty list
On Sun, 23 Jun 2013 15:50:07 +0800, Axel Lin wrote:
> list_first_entry() expects the list is not empty, we need to check if list is
> empty before calling list_first_entry(). Thus use list_first_entry_or_null()
> instead of list_first_entry().
>
> Signed-off-by: Axel Lin
Applied, thanks.
g.
> ---
> drivers/of/irq.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index a3c1c5a..5c645c7 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -482,8 +482,9 @@ void __init of_irq_init(const struct of_device_id
> *matches)
> }
>
> /* Get the next pending parent that might have children */
> - desc = list_first_entry(&intc_parent_list, typeof(*desc), list);
> - if (list_empty(&intc_parent_list) || !desc) {
> + desc = list_first_entry_or_null(&intc_parent_list,
> + typeof(*desc), list);
> + if (!desc) {
> pr_err("of_irq_init: children remain, but no
> parents\n");
> break;
> }
> --
> 1.8.1.2
>
>
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/3] MAINTAINERS: Refactor device tree maintainership
Device tree bindings require a lot more attention than they used to. We've got a group of volunteers willing to take over maintaining bindings. This patch adds them to the MAINTAINERS file. This group still needs to work out a process for maintainership and how they are going to work together. I recommend that they set up a shared tree on git.kernel.org that they each have commit access to similar to the tip tree or the arm-soc tree, but it is up to them. Signed-off-by: Grant Likely Cc: Pawel Moll Cc: Mark Rutland Cc: Stephen Warren Cc: Ian Campbell Cc: Rob Herring Cc: Olof Johansson Cc: devicetree-discuss@lists.ozlabs.org Cc: devicet...@vger.kernel.org --- MAINTAINERS | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index bc286e4..12c95d5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6050,13 +6050,24 @@ L: devicet...@vger.kernel.org W: http://fdt.secretlab.ca T: git git://git.secretlab.ca/git/linux-2.6.git S: Maintained -F: Documentation/devicetree F: drivers/of F: include/linux/of*.h F: scripts/dtc K: of_get_property K: of_match_table +OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS +M: Pawel Moll +M: Mark Rutland +M: Stephen Warren +M: Ian Campbell +L: devicet...@vger.kernel.org +S: Maintained +F: Documentation/devicetree +F: arch/*/boot/dts +F: arch/*/ +F: include/dt-bindings + OPENRISC ARCHITECTURE M: Jonas Bonn W: http://openrisc.net -- 1.8.1.2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] net: Add MOXA ART SoCs ethernet driver
I think this driver may have a bug. After some time running ping successfully, the message "no TX space for packet" is printed resulting in 100% packet loss. The message is printed from .ndo_start_xmit and I think it may be because of how priv->tx_desc_now is now set up in moxart_mac_setup_desc_ring. I will take a look at this and try to fix the issue. Best regards, Jonas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
On 07/19/2013 10:27 AM, Oleksandr Kozaruk wrote: > The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, > known also as Phoenix and PhoenixLite. > > The TWL6030 and TWL6032 have GPADC with 17 and 19 channels > respectively. Some channels have current source and are used for > measuring voltage drop on resistive load for detecting battery ID > resistance, or measuring voltage drop on NTC resistors for external > temperature measurements. Some channels measure voltage, (i.e. battery > voltage), and have voltage dividers, thus, capable to scale voltage. > Some channels are dedicated for measuring die temperature. > > Some channels are calibrated in 2 points, having offsets from ideal > values kept in trim registers. This is used to correct measurements. > > The differences between GPADC in TWL6030 and TWL6032: > - 10 bit vs 12 bit ADC; > - 17 vs 19 channels; > - channels have different purpose(i.e. battery voltage > channel 8 vs channel 18); > - trim values are interpreted differently. > > Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, > Girish S Ghongdemath. > > Signed-off-by: Balaji T K > Signed-off-by: Graeme Gregory > Signed-off-by: Oleksandr Kozaruk A few little bits and bobs inline. My only major query is about the lack of info for the temperature channels. How do you convert these to useful real world units? Jonathan > --- > drivers/iio/adc/Kconfig | 14 + > drivers/iio/adc/Makefile| 1 + > drivers/iio/adc/twl6030-gpadc.c | 991 > > 3 files changed, 1006 insertions(+) > create mode 100644 drivers/iio/adc/twl6030-gpadc.c > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig > index ab0767e6..3172461 100644 > --- a/drivers/iio/adc/Kconfig > +++ b/drivers/iio/adc/Kconfig > @@ -150,6 +150,20 @@ config TI_AM335X_ADC > Say yes here to build support for Texas Instruments ADC > driver which is also a MFD client. > > +config TWL6030_GPADC > + tristate "TWL6030 GPADC (General Purpose A/D Converter) Support" > + depends on TWL4030_CORE > + default n > + help > + Say yes here if you want support for the TWL6030/TWL6032 General > + Purpose A/D Converter. This will add support for battery type > + detection, battery voltage and temperature measurement, die > + temperature measurement, system supply voltage, audio accessory, > + USB ID detection. > + > + This driver can also be built as a module. If so, the module will be > + called twl6030-gpadc. > + > config VIPERBOARD_ADC > tristate "Viperboard ADC support" > depends on MFD_VIPERBOARD && USB > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile > index 0a825be..996ba09 100644 > --- a/drivers/iio/adc/Makefile > +++ b/drivers/iio/adc/Makefile > @@ -16,4 +16,5 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o > obj-$(CONFIG_MAX1363) += max1363.o > obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o > obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o > +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o > obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o > diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c > new file mode 100644 > index 000..b42cfd6 > --- /dev/null > +++ b/drivers/iio/adc/twl6030-gpadc.c > @@ -0,0 +1,991 @@ > +/* > + * TWL6030 GPADC module driver > + * > + * Copyright (C) 2009-2013 Texas Instruments Inc. > + * Nishant Kamat > + * Balaji T K > + * Graeme Gregory > + * Girish S Ghongdemath > + * Ambresh K > + * Oleksandr Kozaruk + * > + * Based on twl4030-madc.c > + * Copyright (C) 2008 Nokia Corporation > + * Mikko Ylinen > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * version 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA > + * > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define DRIVER_NAME "twl6030_gpadc" > + > +#define TWL6030_GPADC_MAX_CHANNELS 17 > +#define TWL6032_GPADC_MAX_CHANNELS 19 > + > +#define TWL6030_GPADC_CTRL_P10x05 > + > +#define TWL6032_GPADC_GPSELECT_ISB 0x07 > +#define TWL6032_GPADC_CTRL_P10x08 > + > +#define TWL6032_GPADC_GPCH0_LSB 0x0d > +#define TWL6032_GPADC_GPCH0_MSB 0x0e > + > +#define TWL6030_GPADC_CTRL_P1_SP1
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Thu, 2013-07-18 at 01:58 +0200, Laurent Pinchart wrote: > Hi Luciano, Hi Laurent, > On Monday 01 July 2013 15:39:30 Luciano Coelho wrote: > > The only thing I can come up with is to make a small clock driver (maybe > > even inside the WiLink module itself) that registers a new type of > > clock, "ti,wilink-clock" or something. But this would really be > > overkill, wouldn't it? > > > > Any other ideas? > > One possibility would be to just call clk_get_rate() on the clock from the > WiLink driver, which would return the fixed frequency specified in DT, and > configure the WiLink hardware accordingly. This might be a bit hackish though. The problem is not get the rate itself, the problem is knowing whether the clock is XTAL or not. The WiLink chip uses the clock in a slightly different way if it is XTAL, due to some stabilization time constraints. -- Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
