| Message ID | 20130805094709.GA29090@e102568-lin.cambridge.arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Aug 5, 2013 at 2:47 AM, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote: > On Mon, Aug 05, 2013 at 05:09:50AM +0100, Olof Johansson wrote: >> Here's a short series on top of Nico's TC2 MCPM series to move the SPC driver >> back under mach-vexpress where it should be, and a couple of tiny cleanups >> to the driver. >> >> I'll pick this up together with the base branch in arm-soc for-next, but I >> haven't staged it in a next/* branch so it can be rebased/changed/dropped >> if needed. >> >> There's still one thing left to iron out, and that's the actual binding >> for the "SPC" node. Since the spc code needs a non-zero SPC_BASE, it >> implies that there's more than just SPC described by the device node. So >> either the naming and description needs to be changed, or there's need >> for more than one device node to describe the other register ranges. The >> former might be easier in this case... >> >> Pawel, I'd appreciate a quick test from you to make sure I didn't break >> anything since I don't have a way to boot this myself. > > Thanks Olof. > > Tested, a couple of fixes needed to compile your series, comments in the > relative patches. Thanks. For some reason I figured vexpress_defconfig would provide build coverage, so it obviously missed build coverage by me. I also missed a git add. > For the bindings, you are right, how about this (commit log written just > for the sake of it, it should be squashed in Nico's original series) ? There's no harm in keeping the change history by having two patches. I'll add this below my series of three when I revise them. -Olof
On Mon, 2013-08-05 at 10:47 +0100, Lorenzo Pieralisi wrote: > For the bindings, you are right, how about this (commit log written just > for the sake of it, it should be squashed in Nico's original series) ? So I finally sat down and did what I should have done long time ago... Read the spec ;-) SCC is (was?) mainly used to set initial conditions for the cores, interconnect and all the other bits and pieces inside the test chip. It could be considered an equivalent of the classic "boot mode" pins, but as test chips have many more of them comparing to the normal SOCs, the data is being "injected" to the chip in a serial fashion *before* the main reset is being de-asserted. This is done by an external entity, namely the DCC (daughterboard configuration controller, so simply a microcontroller living next to the test chip). Why is this detail important at all? Because traditionally the SCC was *not* available in the normal memory map, otherwise it would be a perfect candidate for the . In order to change anything one had to go through the usual Versatile Express config infrastructure. Fortunately there was no need to do this at all... And here comes the V2P-CA15_A7, also known as TC2 ;-) where the interface was re-(or ab-?)used as a "convenient" communication channel between the test chip and the microcontroller. And the SPC is even described as "being merged" with the SCC. Uh... Now, the bottom line. How about keeping the driver look for "arm,vexpress-spc,v2p-ca15_a7" because it's a driver for the SPC bit after all and doing the following in the tree: scc@7fff0000 { compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc"; reg = <0x7fff0000 0x1000>; interrupts = <0 95 4>; spc@b00 { compatible = "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc"; reg = <0xb00 0x100>; }; }; This, I believe, would represent the actual situation, require no change in the driver (except for the retirement of SPC_BASE which is good :-) and allowed as, if and when necessary, to drive the SCC as a MFD/syscon device. Does it make some sense? Pawel
On Tue, Aug 6, 2013 at 9:19 AM, Pawel Moll <pawel.moll@arm.com> wrote: > On Mon, 2013-08-05 at 10:47 +0100, Lorenzo Pieralisi wrote: >> For the bindings, you are right, how about this (commit log written just >> for the sake of it, it should be squashed in Nico's original series) ? > > So I finally sat down and did what I should have done long time ago... > Read the spec ;-) Uh... Ok. Biting my tongue. :) Is the spec public, per chance? > SCC is (was?) mainly used to set initial conditions for the cores, > interconnect and all the other bits and pieces inside the test chip. It > could be considered an equivalent of the classic "boot mode" pins, but > as test chips have many more of them comparing to the normal SOCs, the > data is being "injected" to the chip in a serial fashion *before* the > main reset is being de-asserted. This is done by an external entity, > namely the DCC (daughterboard configuration controller, so simply a > microcontroller living next to the test chip). Why is this detail > important at all? Because traditionally the SCC was *not* available in > the normal memory map, otherwise it would be a perfect candidate for > the . In order to change anything one had to go through the usual > Versatile Express config infrastructure. Fortunately there was no need > to do this at all... Vexpress is such a hack. :) It's unfortunate that it ends up being the lead platform on these kind of technologies, in some ways. I think it makes sense to hide some of this ick in mach-vexpress, I don't think we should ever aim to empty it out. Not based on how messy the platform architecture is. I'd rather hide it in there than pollute other parts of the kernel. Or at least, we should keep it as an option in some cases such as these -- there might be other parts that do make sense to move out to generic kernel. > And here comes the V2P-CA15_A7, also known as TC2 ;-) where the > interface was re-(or ab-?)used as a "convenient" communication channel > between the test chip and the microcontroller. And the SPC is even > described as "being merged" with the SCC. Uh... > > Now, the bottom line. How about keeping the driver look for > "arm,vexpress-spc,v2p-ca15_a7" because it's a driver for the SPC bit > after all and doing the following in the tree: > > scc@7fff0000 { > compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc"; > reg = <0x7fff0000 0x1000>; > interrupts = <0 95 4>; > > spc@b00 { > compatible = "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc"; > reg = <0xb00 0x100>; > }; > }; > > This, I believe, would represent the actual situation, require no change > in the driver (except for the retirement of SPC_BASE which is good :-) > and allowed as, if and when necessary, to drive the SCC as a MFD/syscon > device. > > Does it make some sense? It does, but you need to setup the scc as a bus (with ranges, etc) for that binding to work. I pushed the fixed-up set of patches to the branch in arm-soc, so you can find them there (olof/vexpress). Sounds like this isn't quite ready to merge if these things still need to be worked out. So feel free to take my patches, change them up as needed and send a fresh copy. Or, if you want to rebase the whole series and squash things in with Nico's patches, that's ok too. But sounds like it needs a little more work still. 3.12 is still a realistic target though. -Olof
On Tue, Aug 06, 2013 at 05:19:53PM +0100, Pawel Moll wrote: > On Mon, 2013-08-05 at 10:47 +0100, Lorenzo Pieralisi wrote: > > For the bindings, you are right, how about this (commit log written just > > for the sake of it, it should be squashed in Nico's original series) ? > > So I finally sat down and did what I should have done long time ago... > Read the spec ;-) > > SCC is (was?) mainly used to set initial conditions for the cores, > interconnect and all the other bits and pieces inside the test chip. It > could be considered an equivalent of the classic "boot mode" pins, but > as test chips have many more of them comparing to the normal SOCs, the > data is being "injected" to the chip in a serial fashion *before* the > main reset is being de-asserted. This is done by an external entity, > namely the DCC (daughterboard configuration controller, so simply a > microcontroller living next to the test chip). Why is this detail > important at all? Because traditionally the SCC was *not* available in > the normal memory map, otherwise it would be a perfect candidate for > the . In order to change anything one had to go through the usual > Versatile Express config infrastructure. Fortunately there was no need > to do this at all... > > And here comes the V2P-CA15_A7, also known as TC2 ;-) where the > interface was re-(or ab-?)used as a "convenient" communication channel > between the test chip and the microcontroller. And the SPC is even > described as "being merged" with the SCC. Uh... Yes, the "merging" of SCC and SPC is the root cause of this hopefully happy ended story, they lumped together pieces of HW that should have been kept separate. > Now, the bottom line. How about keeping the driver look for > "arm,vexpress-spc,v2p-ca15_a7" because it's a driver for the SPC bit > after all and doing the following in the tree: > > scc@7fff0000 { > compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc"; > reg = <0x7fff0000 0x1000>; > interrupts = <0 95 4>; > > spc@b00 { > compatible = "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc"; > reg = <0xb00 0x100>; > }; > }; > > This, I believe, would represent the actual situation, require no change > in the driver (except for the retirement of SPC_BASE which is good :-) > and allowed as, if and when necessary, to drive the SCC as a MFD/syscon > device. I do need some SCC registers to check the cluster ID against the MPIDR in order to carry out powerdown operations. So if we do what you suggest we have to change the driver, I would avoid doing that at this stage. > Does it make some sense? Well, it does but it complicates our lives for not much IMHO (and Olof mentioned that in the cover letter). I still need to map the SCC as a whole to read some IDs registers as I mentioned. We can find a way to make SPC part of a MFD device later on. Lorenzo
On Tue, 2013-08-06 at 17:44 +0100, Olof Johansson wrote: > On Tue, Aug 6, 2013 at 9:19 AM, Pawel Moll <pawel.moll@arm.com> wrote: > > On Mon, 2013-08-05 at 10:47 +0100, Lorenzo Pieralisi wrote: > >> For the bindings, you are right, how about this (commit log written just > >> for the sake of it, it should be squashed in Nico's original series) ? > > > > So I finally sat down and did what I should have done long time ago... > > Read the spec ;-) > > Uh... Ok. Biting my tongue. :) > > Is the spec public, per chance? Not the one I had to go to understand the implementation details, no. > > SCC is (was?) mainly used to set initial conditions for the cores, > > interconnect and all the other bits and pieces inside the test chip. It > > could be considered an equivalent of the classic "boot mode" pins, but > > as test chips have many more of them comparing to the normal SOCs, the > > data is being "injected" to the chip in a serial fashion *before* the > > main reset is being de-asserted. This is done by an external entity, > > namely the DCC (daughterboard configuration controller, so simply a > > microcontroller living next to the test chip). Why is this detail > > important at all? Because traditionally the SCC was *not* available in > > the normal memory map, otherwise it would be a perfect candidate for > > the . In order to change anything one had to go through the usual > > Versatile Express config infrastructure. Fortunately there was no need > > to do this at all... > > Vexpress is such a hack. :) I think I can say "thank you" on behalf of our board designers :-P :-) Now, seriously speaking. It is a complex design, no question about that. It has flaws, and I'm the first one to name the cock-ups (at least internally). And some of the solutions may seem "over engineered" at first. But the ultimate goal here was flexibility. You can change pretty much everything here - most of the motherboard peripherals live in a FPGA, we have more than one SMM (FPGA-based core implementation). And it came at the cost. > It's unfortunate that it ends up being the > lead platform on these kind of technologies, in some ways. You've just named the reason. It delivers technology before the technology is mature. So I don't think it's fair to compare it with final platforms. > I think it makes sense to hide some of this ick in mach-vexpress, I > don't think we should ever aim to empty it out. I dare to disagree. And the reason is simple - arch/arm64. It's vexpress as well, and we'll be in the same position. That's why I like the "drivers/platform/vexpress" idea a lot. It's tucked away enough not to offend usual by-passers while still being out of arch. > Not based on how messy the platform architecture is. De gustibus non est disputandum. But anyway, it's my job to hide the details behind as many of the generic interfaces as possible. There are two main bones of contention now. The config infrastructure, which I am working on (it will be hidden behind standard regmap API, so you won't even notice it exists ;-). The other is the Power Management, which has the unfortunate problem that we're not sure what are we getting into yet. > I'd rather hide it in there than pollute > other parts of the kernel. Or at least, we should keep it as an option > in some cases such as these -- there might be other parts that do make > sense to move out to generic kernel. And this is exactly what we're trying to do. Keep it all in one place. > > And here comes the V2P-CA15_A7, also known as TC2 ;-) where the > > interface was re-(or ab-?)used as a "convenient" communication channel > > between the test chip and the microcontroller. And the SPC is even > > described as "being merged" with the SCC. Uh... > > > > Now, the bottom line. How about keeping the driver look for > > "arm,vexpress-spc,v2p-ca15_a7" because it's a driver for the SPC bit > > after all and doing the following in the tree: > > > > scc@7fff0000 { > > compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc"; > > reg = <0x7fff0000 0x1000>; > > interrupts = <0 95 4>; > > > > spc@b00 { > > compatible = "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc"; > > reg = <0xb00 0x100>; > > }; > > }; > > > > This, I believe, would represent the actual situation, require no change > > in the driver (except for the retirement of SPC_BASE which is good :-) > > and allowed as, if and when necessary, to drive the SCC as a MFD/syscon > > device. > > > > Does it make some sense? > > It does, but you need to setup the scc as a bus (with ranges, etc) for > that binding to work. Sure, it was just an example. > I pushed the fixed-up set of patches to the branch in arm-soc, so you > can find them there (olof/vexpress). Sounds like this isn't quite > ready to merge if these things still need to be worked out. So feel > free to take my patches, change them up as needed and send a fresh > copy. Ok, will do. Pawe?
On Tue, 2013-08-06 at 17:55 +0100, Lorenzo Pieralisi wrote: > > And here comes the V2P-CA15_A7, also known as TC2 ;-) where the > > interface was re-(or ab-?)used as a "convenient" communication channel > > between the test chip and the microcontroller. And the SPC is even > > described as "being merged" with the SCC. Uh... > > Yes, the "merging" of SCC and SPC is the root cause of this hopefully happy > ended story, they lumped together pieces of HW that should have been kept > separate. Show me an SOC when the silicon people didn't try to save silicon area and pads, for the cost of "solutions" like this... > > Now, the bottom line. How about keeping the driver look for > > "arm,vexpress-spc,v2p-ca15_a7" because it's a driver for the SPC bit > > after all and doing the following in the tree: > > > > scc@7fff0000 { > > compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc"; > > reg = <0x7fff0000 0x1000>; > > interrupts = <0 95 4>; > > > > spc@b00 { > > compatible = "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc"; > > reg = <0xb00 0x100>; > > }; > > }; > > > > This, I believe, would represent the actual situation, require no change > > in the driver (except for the retirement of SPC_BASE which is good :-) > > and allowed as, if and when necessary, to drive the SCC as a MFD/syscon > > device. > > I do need some SCC registers to check the cluster ID against the MPIDR in > order to carry out powerdown operations. So if we do what you suggest we have > to change the driver, I would avoid doing that at this stage. That's what I'm saying - if we do the binding right, you won't have to change the driver at all. It will do the same of_find_compatible_node(NULL, NULL, "arm,vexpress-spc,v2p-ca15_a7"); as previously. Pawe?
On Tue, Aug 06, 2013 at 05:44:55PM +0100, Olof Johansson wrote: > On Tue, Aug 6, 2013 at 9:19 AM, Pawel Moll <pawel.moll@arm.com> wrote: > > On Mon, 2013-08-05 at 10:47 +0100, Lorenzo Pieralisi wrote: > >> For the bindings, you are right, how about this (commit log written just > >> for the sake of it, it should be squashed in Nico's original series) ? > > > > So I finally sat down and did what I should have done long time ago... > > Read the spec ;-) > > Uh... Ok. Biting my tongue. :) > > Is the spec public, per chance? I will check. > > SCC is (was?) mainly used to set initial conditions for the cores, > > interconnect and all the other bits and pieces inside the test chip. It > > could be considered an equivalent of the classic "boot mode" pins, but > > as test chips have many more of them comparing to the normal SOCs, the > > data is being "injected" to the chip in a serial fashion *before* the > > main reset is being de-asserted. This is done by an external entity, > > namely the DCC (daughterboard configuration controller, so simply a > > microcontroller living next to the test chip). Why is this detail > > important at all? Because traditionally the SCC was *not* available in > > the normal memory map, otherwise it would be a perfect candidate for > > the . In order to change anything one had to go through the usual > > Versatile Express config infrastructure. Fortunately there was no need > > to do this at all... > > Vexpress is such a hack. :) It's unfortunate that it ends up being the > lead platform on these kind of technologies, in some ways. > > I think it makes sense to hide some of this ick in mach-vexpress, I > don't think we should ever aim to empty it out. Not based on how messy > the platform architecture is. I'd rather hide it in there than pollute > other parts of the kernel. Or at least, we should keep it as an option > in some cases such as these -- there might be other parts that do make > sense to move out to generic kernel. > > > And here comes the V2P-CA15_A7, also known as TC2 ;-) where the > > interface was re-(or ab-?)used as a "convenient" communication channel > > between the test chip and the microcontroller. And the SPC is even > > described as "being merged" with the SCC. Uh... > > > > Now, the bottom line. How about keeping the driver look for > > "arm,vexpress-spc,v2p-ca15_a7" because it's a driver for the SPC bit > > after all and doing the following in the tree: > > > > scc@7fff0000 { > > compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc"; > > reg = <0x7fff0000 0x1000>; > > interrupts = <0 95 4>; > > > > spc@b00 { > > compatible = "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc"; > > reg = <0xb00 0x100>; > > }; > > }; > > > > This, I believe, would represent the actual situation, require no change > > in the driver (except for the retirement of SPC_BASE which is good :-) > > and allowed as, if and when necessary, to drive the SCC as a MFD/syscon > > device. > > > > Does it make some sense? > > It does, but you need to setup the scc as a bus (with ranges, etc) for > that binding to work. > > I pushed the fixed-up set of patches to the branch in arm-soc, so you > can find them there (olof/vexpress). Sounds like this isn't quite > ready to merge if these things still need to be worked out. So feel > free to take my patches, change them up as needed and send a fresh > copy. No, please, no. By no means MCPM for TC2 should be delayed for longer by a piece of HW that is giving me (and unfortunately you too) the time of my life. We moved code to mach-vexpress, trimmed it to just a bunch of regs reads and writes, and put it where it belongs, in platform specific code. There is still room for making the SCC a proper MFD/syscon device, but not now, it makes no sense to delay this code for something that we might not even come to implement. Let's get it through as it is, please. Lorenzo
On Tue, Aug 6, 2013 at 10:03 AM, Pawel Moll <pawel.moll@arm.com> wrote: > I dare to disagree. And the reason is simple - arch/arm64. It's vexpress > as well, and we'll be in the same position. Actually, no -- PSCI will be mandatory there so there will be no need to have these kernel components. -Olof
On Tue, 2013-08-06 at 18:25 +0100, Olof Johansson wrote: > > I dare to disagree. And the reason is simple - arch/arm64. It's vexpress > > as well, and we'll be in the same position. > > Actually, no -- PSCI will be mandatory there so there will be no need > to have these kernel components. Oh, SPC must die with TC2, no argument from me here. That's why I don't really mind it being in arch/arm/mach-vexpress today. If it turns out that it's the last and only thing there, we can discuss it again. Pawe?
diff --git a/Documentation/devicetree/bindings/arm/vexpress-scc.txt b/Documentation/devicetree/bindings/arm/vexpress-scc.txt new file mode 100644 index 0000000..f25849d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/vexpress-scc.txt @@ -0,0 +1,37 @@ +* ARM Versatile Express Serial Configuration Controller device tree bindings + +Latest ARM development boards implement a serial configuration interface (SCC) +that can be used to retrieve temperature sensors, energy/voltage/current +probes and oscillators values through the SYS configuration protocol defined +for versatile express motherboards. +It also provides a power management interface (serial power controller - SPC) +that is capable of managing power/voltage and operating points transitions, +wake-up IRQs and resume addresses for ARM multiprocessor testchips. + +The SCC DT bindings are defined as follows: + +- scc node + + - compatible: + Usage: required + Value type: <stringlist> + Definition: must be + "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc" + - reg: + Usage: required + Value type: <prop-encode-array> + Definition: A standard property that specifies the base address + and the size of the SCC address space + - interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: SCC interrupt configuration. A standard property + that follows ePAPR interrupts specifications + +Example: + +scc: scc@7fff0000 { + compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc"; + reg = <0x7fff0000 0x1000>; + interrupts = <0 95 4>; +}; diff --git a/Documentation/devicetree/bindings/arm/vexpress-spc.txt b/Documentation/devicetree/bindings/arm/vexpress-spc.txt deleted file mode 100644 index 1614725..0000000 --- a/Documentation/devicetree/bindings/arm/vexpress-spc.txt +++ /dev/null @@ -1,36 +0,0 @@ -* ARM Versatile Express Serial Power Controller device tree bindings - -Latest ARM development boards implement a power management interface (serial -power controller - SPC) that is capable of managing power states transitions, -wake-up IRQs and resume addresses for ARM multiprocessor testchips. -The serial controller can be programmed through a memory mapped interface -that enables communication between firmware running on the microcontroller -managing power states and the application processors. - -The SPC DT bindings are defined as follows: - -- spc node - - - compatible: - Usage: required - Value type: <stringlist> - Definition: must be - "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc" - - reg: - Usage: required - Value type: <prop-encode-array> - Definition: A standard property that specifies the base address - and the size of the SPC address space - - interrupts: - Usage: required - Value type: <prop-encoded-array> - Definition: SPC interrupt configuration. A standard property - that follows ePAPR interrupts specifications - -Example: - -spc: spc@7fff0000 { - compatible = "arm,vexpress-spc,v2p-ca15_a7", "arm,vexpress-spc"; - reg = <0x7fff0000 0x1000>; - interrupts = <0 95 4>; -};