Re: [PATCH 1/2] ARM: shmobile: irqpin: add a DT property to enable masking on parent
On Wed, Jun 12, 2013 at 05:38:50PM +0900, Simon Horman wrote: On Tue, Jun 11, 2013 at 06:37:24PM +0900, Magnus Damm wrote: On Fri, May 24, 2013 at 6:13 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: To disable spurious interrupts, that get triggered on certain hardware, the irqpin driver masks them on the parent interrupt controller. To specify such broken devices a .control_parent parameter can be provided in the platform data. In the DT case we need a property, to do the same. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- These two patches simply split the earlier ARM: shmobile: irqpin: fix handling of spurious interrupts in DT case patch into two parts. Otherwise no change. I'm fine with this portion of the patch series. Thanks for your help! Acked-by: Magnus Damm d...@opensource.se I believe that this patch depends on irqchip: renesas-intc-irqpin: DT binding for sense bitfield width which Arnd has requested some modifications to. I think you should add documentation here about how the two interrupt cells are to be interpreted, to allow people to fill the values from a data sheet or board schematic. http://www.spinics.net/lists/linux-sh/msg20202.html Please post a fresh series that: 1. Includes a fresh version of irqchip: renesas-intc-irqpin: DT binding for sense bitfield width with Arnd's concerns addressed. 2. Includes this patch with Magnus's Ack. Please be sure to CC Arnd on the new series. Hi Guennadi, I see that you reposted irqchip: renesas-intc-irqpin: DT binding for sense bitfield width, which I have queued-up, without this patch. Please rebase this patch and repost it with Magnus's Ack. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver
On Tue, Jun 18, 2013 at 9:33 AM, Wolfram Sang w...@the-dreams.de wrote: On Mon, Jun 17, 2013 at 11:15:30PM +0100, Grant Likely wrote: On Mon, Jun 17, 2013 at 5:33 PM, Linus Walleij linus.wall...@linaro.org wrote: OK that works for me, I'm not in any hurry. Deferring by a merge window isn't going to make it any less painful. Do your best to find all the users that need to be changed. Use a coccinelle search perhaps, but I think it should be merged anyway. I'll try a bit of my coccinelle-foo today and then decide. Thanks Wolfram, much appreciated. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 0/3] SH pinctrl DT support
On Mon, Jun 17, 2013 at 8:50 PM, Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com wrote: Hello, Here's the seventh (and hopefully final) version of the SuperH and SH Mobile pin controllers (PFC) DT support patch set. The patches have been rebased on the for-next branch of the pinctrl repository. All ARM-specific patches have been dropped and will be pushed through to ARM SoC tree in v3.12. This series thus only contains DT support for the sh-pfc driver. I've tried merging Simon's latest tag (renesas-next-20130617v3) with these patches and no conflict occurred. Linus, would it finally be possible to get this applied for v3.11 ? Changes since v6: - Added generic pinconf support back - Dropped all ARM-specific patches Thanks, this looks really nice and I've applied all three. Heiko, James can you have a look from a generic pinconf point of view so we are sure we get this right? (Looks right to me atleast.) Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 3/3] DMA: shdma: add DT support
Hi Arnd
On Mon, 17 Jun 2013, Arnd Bergmann wrote:
On Thursday 06 June 2013, Guennadi Liakhovetski wrote:
+Required properties:
+- dmas:a list of [DMA controller phandle] [MID/RID value]
pairs
+- dma-names: a list of DMA channel names, one per dmas entry
Looks ok to me, although it might be helpful to clarify what MID/RID means,
by expanding the acronym and describing whether one needs to pass both
or just one of them. If both, what is the bit pattern?
One word: magic. MID/RID is what that value is called in the datasheet.
E.g. on APE6 (r8a73a4) it is indeed divided into 2 fields - 2 and 6 bits
for RID and MID respectively, I _guess_ 2 bits are to select a channel
within a slave device and 6 bits to pick up one of slaves, but that
doesn't fit with a slave with 8 channels (HSI), there are also slave
devices with different MID values, so, those values are really better
considered as a single magic value - an 8-bit channel request handle,
which is also how they are listed in a reference table.
* services would have to provide their own filters, which first would
check
* the device driver, similar to how other DMAC drivers, e.g.,
sa11x0-dma.c, do
* this, and only then, in case of a match, call this common filter.
+ * NOTE 2: This filter function is also used in the DT case by
shdma_xlate().
+ * In that case the MID-RID value is used for slave channel filtering and
is
+ * passed to this function in the arg parameter.
*/
bool shdma_chan_filter(struct dma_chan *chan, void *arg)
{
struct shdma_chan *schan = to_shdma_chan(chan);
struct shdma_dev *sdev = to_shdma_dev(schan-dma_chan.device);
const struct shdma_ops *ops = sdev-ops;
- int slave_id = (int)arg;
+ int match = (int)arg;
int ret;
- if (slave_id 0)
+ if (match 0)
/* No slave requested - arbitrary channel */
return true;
- if (slave_id = slave_num)
+ if (!schan-dev-of_node match = slave_num)
return false;
- ret = ops-set_slave(schan, slave_id, true);
+ ret = ops-set_slave(schan, match, true);
if (ret 0)
return false;
This is complicated by the fact that you are using the same function for
two entirely different purposes. It would be easier to have a separate
filter for the DT case, rather than reusing the one that uses the slave_id
as an argument.
Hm, yes, I was considering either making 2 functions or reusing one, but
it's really the same code with only difference - the DT version wouldn't
have the slave_num check. So, I decided to use a single function
renaming slave_id to a neutral match. You really think it's become too
complex and should be copied for clarity?
@@ -867,6 +883,29 @@ void shdma_chan_remove(struct shdma_chan *schan)
}
EXPORT_SYMBOL(shdma_chan_remove);
+struct dma_chan *shdma_xlate(struct of_phandle_args *dma_spec,
+struct of_dma *ofdma)
+{
+ struct shdma_dev *sdev = ofdma-of_dma_data;
+ u32 id = dma_spec-args[0];
+ dma_cap_mask_t mask;
+ struct dma_chan *chan;
+
+ if (dma_spec-args_count != 1 || !sdev)
+ return NULL;
+
+ dma_cap_zero(mask);
+ /* Only slave DMA channels can be allocated via DT */
+ dma_cap_set(DMA_SLAVE, mask);
+
+ chan = dma_request_channel(mask, shdma_chan_filter, (void *)id);
+ if (chan)
+ to_shdma_chan(chan)-hw_req = id;
+
+ return chan;
+}
+EXPORT_SYMBOL(shdma_xlate);
I would suggest keeping this to the drivers/dma/sh/shdma.c file
and not exporting it. The sudma would use a different binding anyway.
Ok, can do that and then see, how different sudma's .xlate() function will
be. If it's the same we can make this common again.
+/*
+ * Find a slave channel configuration from the contoller list by either a
slave
+ * ID in the non-DT case, or by a MID/RID value in the DT case
+ */
static const struct sh_dmae_slave_config *dmae_find_slave(
- struct sh_dmae_chan *sh_chan, int slave_id)
+ struct sh_dmae_chan *sh_chan, int match)
{
struct sh_dmae_device *shdev = to_sh_dev(sh_chan);
struct sh_dmae_pdata *pdata = shdev-pdata;
const struct sh_dmae_slave_config *cfg;
int i;
- if (slave_id = SH_DMA_SLAVE_NUMBER)
- return NULL;
+ if (!sh_chan-shdma_chan.dev-of_node) {
+ if (match = SH_DMA_SLAVE_NUMBER)
+ return NULL;
- for (i = 0, cfg = pdata-slave; i pdata-slave_num; i++, cfg++)
- if (cfg-slave_id == slave_id)
- return cfg;
+ for (i = 0, cfg = pdata-slave; i pdata-slave_num; i++,
cfg++)
+ if (cfg-slave_id == match)
+ return cfg;
+ } else {
+ for (i = 0, cfg = pdata-slave; i pdata-slave_num; i++,
cfg++)
+ if (cfg-mid_rid == match) {
Re: [PATCH v7 0/3] SH pinctrl DT support
On 18/06/13 09:05, Linus Walleij wrote: On Mon, Jun 17, 2013 at 8:50 PM, Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com wrote: Hello, Here's the seventh (and hopefully final) version of the SuperH and SH Mobile pin controllers (PFC) DT support patch set. The patches have been rebased on the for-next branch of the pinctrl repository. All ARM-specific patches have been dropped and will be pushed through to ARM SoC tree in v3.12. This series thus only contains DT support for the sh-pfc driver. I've tried merging Simon's latest tag (renesas-next-20130617v3) with these patches and no conflict occurred. Linus, would it finally be possible to get this applied for v3.11 ? Changes since v6: - Added generic pinconf support back - Dropped all ARM-specific patches Thanks, this looks really nice and I've applied all three. Heiko, James can you have a look from a generic pinconf point of view so we are sure we get this right? (Looks right to me atleast.) The generic pinconf stuff in these patches looks reasonable to me. Should we be standardizing the pins/groups/function properties too, since the strings are pretty much passed straight through? The usage seems pretty similar between the drivers I've seen (except ugly vendor prefixes), so we could presumably get away with a single implementation of dt_node_to_map? Cheers James ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] mfd: twl4030-power: Split from twl-core into a dedicated module
Hello,
Thank you for the review.
On 06/18/2013 01:56 AM, Samuel Ortiz wrote:
Hi Florian,
On Thu, May 30, 2013 at 03:51:54PM +0200, Florian Vaussard wrote:
For now, the call to twl4030-power is hard-wired inside twl-core.
To ease the future transition to DT, make twl4030-power as a
separate module, like what is already done for twl4030-audio
and others.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
drivers/mfd/twl-core.c | 12 ++---
drivers/mfd/twl4030-power.c | 54 +++
include/linux/i2c/twl.h |1 -
3 files changed, 52 insertions(+), 15 deletions(-)
Looks good, I only have one comment:
+static struct platform_driver twl4030_power_driver = {
+ .driver = {
+ .name = twl4030_power,
+ .owner = THIS_MODULE,
+ },
+ .probe = twl4030_power_probe,
+ .remove = twl4030_power_remove,
+};
+
+static int __init twl4030_power_init(void)
+{
+ return platform_driver_register(twl4030_power_driver);
}
+subsys_initcall(twl4030_power_init);
+
+static void __exit twl4030_power_exit(void)
+{
+ platform_driver_unregister(twl4030_power_driver);
+}
+module_exit(twl4030_power_exit);
Please use module_platform_driver() here.
Sure!
Regards,
Florian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 0/3] SH pinctrl DT support
Am Dienstag, 18. Juni 2013, 10:05:30 schrieb Linus Walleij: On Mon, Jun 17, 2013 at 8:50 PM, Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com wrote: Hello, Here's the seventh (and hopefully final) version of the SuperH and SH Mobile pin controllers (PFC) DT support patch set. The patches have been rebased on the for-next branch of the pinctrl repository. All ARM-specific patches have been dropped and will be pushed through to ARM SoC tree in v3.12. This series thus only contains DT support for the sh-pfc driver. I've tried merging Simon's latest tag (renesas-next-20130617v3) with these patches and no conflict occurred. Linus, would it finally be possible to get this applied for v3.11 ? Changes since v6: - Added generic pinconf support back - Dropped all ARM-specific patches Thanks, this looks really nice and I've applied all three. Heiko, James can you have a look from a generic pinconf point of view so we are sure we get this right? (Looks right to me atleast.) the pinconfig handling looks nice to me. Acked-by: Heiko Stuebner he...@sntech.de ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] mfd: twl4030-power: Start transition to DT
Hello,
On 06/18/2013 02:02 AM, Samuel Ortiz wrote:
Hi Florian,
On Thu, May 30, 2013 at 03:51:55PM +0200, Florian Vaussard wrote:
int twl4030_power_probe(struct platform_device *pdev)
{
struct twl4030_power_data *pdata = pdev-dev.platform_data;
+ struct device_node *node = pdev-dev.of_node;
int err = 0;
- int i;
- struct twl4030_resconfig *resconfig;
- u8 val, address = twl4030_start_script_address;
+ u8 val;
+
+ if (!pdata !node) {
+ dev_err(pdev-dev, Platform data is missing\n);
+ return -EINVAL;
+ }
err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, TWL4030_PM_MASTER_KEY_CFG1,
TWL4030_PM_MASTER_PROTECT_KEY);
@@ -525,26 +575,17 @@ int twl4030_power_probe(struct platform_device *pdev)
if (err)
goto unlock;
- for (i = 0; i pdata-num; i++) {
- err = load_twl4030_script(pdata-scripts[i], address);
+ if (pdata) {
+ err = twl4030_power_configure_scripts(pdata);
if (err)
goto load;
- address += pdata-scripts[i]-size;
- }
-
- resconfig = pdata-resource_config;
- if (resconfig) {
- while (resconfig-resource) {
- err = twl4030_configure_resource(resconfig);
- if (err)
- goto resource;
- resconfig++;
-
- }
+ err = twl4030_power_configure_resources(pdata);
+ if (err)
+ goto resource;
You're simplifying the probe routine here by defining 2
twl4030_power_configure_* functions. That's good, but it should be a
separate patch as it's not related to the DT porting effort.
I agree. I will post a v2 with the changes.
Regards,
Florian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] dmaengine: add support for DMA multiplexer DT nodes
Hi Arnd
Thanks for your comments
On Mon, 17 Jun 2013, Arnd Bergmann wrote:
On Thursday 06 June 2013, Guennadi Liakhovetski wrote:
Documentation/devicetree/bindings/dma/dma.txt | 44
+
drivers/dma/of-dma.c | 31 +
2 files changed, 67 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
index 8f504e6..a861298 100644
--- a/Documentation/devicetree/bindings/dma/dma.txt
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -31,6 +31,50 @@ Example:
dma-requests = 127;
};
+* DMA multiplexer
+
+Several DMA controllers with the same #dma-cells number and the same
request
+line IDs can be grouped under a DMA multiplexer super-node, if slaves can
use
+DMA channels on any of them.
+
+Required property:
+- compatible: Must include dma-mux.
+
+Some standard optional properties can be helpful:
+
+Optional properties:
+- compatible: You will probably also want to include
compatibility
+ with simple-bus to automatically create platform
+ devices from subnodes.
+- ranges: Map DMA controller memory areas in the parent address
+ space.
+- #address-cells: Number of address cells in case automatic propagation
+ with the help of ranges doesn't work.
+- #size-cells: Number of size cells.
+
+Example:
+
+ dmac: dma-mux {
+ compatible = simple-bus, dma-mux;
+ ranges;
+
+ dma0: dma@1000 {
+ #dma-cells = 1;
+ ...
+ };
+
+ dma1: dma@2000 {
+ #dma-cells = 1;
+ ...
+ };
+ };
+
+ mmc0: mmc@3000 {
+ dmas = dmac 1
+ dmac 2;
+ dma-names = tx, rx;
+ ...
+ };
* DMA client
Hmm, you've clearly shown that this can work, but it feels like a really odd
way to
do this. I don't think we should do it this way, because it tries to be really
generic but then cannot some of the interesting cases, e.g.
1. you have multiplexed dma engines, but they need different #dma-cells.
1. you have multiplexed dma engines, but they need different dma specifiers.
2. The mux is between devices that are not on the same parent bus.
Yes, I know about these restrictions. I'm not sure whether we really ever
will get DMA multiplexers with different #dma-cells or DMA specifiers, but
in any case we can make this less generic - either keep it as a generic
uniform multiplexer or making it shdma specific - I'm fine either way.
I think this should either not try to be fully generic and just limited to
the case you care about, i.e. shdma, or it should be more abstract and
multiplex between the individual channels. In either case, I guess
it would not need a change like this to the of_dma_request_slave_channel()
function, and the node pointer used by the slave would be the same node
that defines the address space for the channel descriptions with #dma-cells.
I think the easiest way would be the first of those two, so it would
essentially look like
dmac: dma-mux {
compatible = renesas,shdma-mux; /* not simple-bus! */
#dma-cells = 1;
#address-cells = 1;
#size-cells = 1;
dma@1000 {
compatible = renesas,shdma;
reg = 0x1000 0x1000;
interrupts = 10;
};
dma@2000 {
compatible = renesas,shdma;
reg = 0x1000 0x1000;
interrupts = 10;
};
}
You then register a device driver for the master device, which
will call of_dma_controller_register() for itself and create
its child devices.
Hmm, it is an interesting idea to only register one struct of_dma instance
for all compatible shdma instances instead of one per shdma controller,
and then call of_platform_populate() to instantiate all shdma instances. A
couple of drawbacks:
1. we'll always have to put a mux DT node in .dts, even if there's just
one DMAC instance on the system.
2. as AUXDATA for the new wrapper device we'll have to use an AUXDATA
array for all child nodes, to be passed to of_platform_populate().
3. it seems confusing to me - having one ofdma instance for multiple
dmaengine devices.
The advantage is, of course, that we don't need to extend existing OF and
dmaengine APIs.
So, I think, it can be done this way, but do you really think it'd be an
improvement over my original proposal?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance
Re: [PATCH v2 1/3] ARM: mach-moxart: add MOXA ART SoC files
I may have submitted this one too early. There are now a few things I want to address: * rename moxart_uc7112lx_defconfig moxart_defconfig * remove MACH_UC7112LX default y from arch/arm/mach-moxart/Kconfig Also, the omitted arch/arm/mach-moxart/idle.c hinges on a patch now submitted to Russell's patch tracker: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7760/1 Best regards, Jonas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
Hi Olof, On Mon, Jun 17, 2013 at 10:44:51AM -0700, Olof Johansson wrote: On Mon, Jun 17, 2013 at 04:51:09PM +0100, Lorenzo Pieralisi wrote: The TC2 versatile express core tile integrates a logic block that provides the interface between the dual cluster test-chip and the M3 microcontroller that carries out power management. The logic block, called Serial Power Controller (SPC), contains several memory mapped registers to control among other things low-power states, operating points and reset control. This patch provides a driver that enables run-time control of features implemented by the SPC control logic. The SPC control logic is required to be programmed very early in the boot process to reset secondary CPUs on the TC2 testchip, set-up jump addresses and wake-up IRQs for power management. Since the SPC logic is also used to control clocks and operating points, that have to be initialized early as well, the SPC interface consumers can not rely on early initcalls ordering, which is inconsistent, to wait for SPC initialization. Hence, in order to keep the components relying on the SPC coded in a sane way, the driver puts in place a synchronization scheme that allows kernel drivers to check if the SPC driver has been initialized and if not, to initialize it upon check. A status variable is kept in memory so that loadable modules that require SPC interface (eg CPUfreq drivers) can still check the correct initialization and use the driver correctly after functions used at boot to init the driver are freed. The driver also provides a bridge interface through the vexpress config infrastructure. Operations allowing to read/write operating points are made to go via the same interface as configuration transactions so that all requests to M3 are serialized. Device tree bindings documentation for the SPC component is provided with the patchset. Sorry, I got to think of this over the weekend and should have replied before you had a chance to repost, but still: Why is the operating point and frequency change code in this driver at all? Usually, the MFD driver contains a shared method to access register space on a multifunction device, but the actual operation of each subdevice is handled by individual drivers in the regular locations. I suppose that's what I meant with my initial comment: Why is that stuff under drivers/mfd/ ? So, in the case of operating points and requencies, that should be in a cpufreq driver. And the clock setup should presumably be in a clk framework driver if needed. Yep, several drivers do that already. Then all that would be left here is the functionality for submitting the two kinds of commands, and handling interrupts. That'll trim down the driver to a point where I think you'll find it much easier to get merged. :-) Definitely, yes. And the code would be a lot easier to review and maintain too. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 0/2] drivers: mfd: Versatile Express SPC support
Hi Pawell, On Thu, Jun 13, 2013 at 10:45:57AM +0100, Pawel Moll wrote: On Thu, 2013-06-13 at 01:13 +0100, Samuel Ortiz wrote: Now, about the driver itself, besides the really odd code design, the static variables all over the place, the nasty init hacks and the unneeded long function names, someone should refresh my memory and explain to me why is this guy under mfd. I can see it somehow supports IP blocks providing different functions, but the design is not sharing anything with most of the rest of the mfd drivers. I belive the vexpress-sysreg.c is a Multi Function Device by all means. It does so many things that only a water fountain is missing ;-) If you feel strongly about it, I'm ready to split it into mfd_cells and move the gpio and leds code into separate drivers, however I'm not convinced that it's worth the effort. Well, after seeing your last patch for ifdef'ing the GPIO and LED code, I think it is worth the effort. Now, as to the vexpress-config.c... The first time I've posted the series, all parts lived in driver/misc(/vexpress), but (if I remember correctly) Arnd had some feelings about misc existence at all... I was thinking about a separate directory for random system/platform/machine configuration drivers, but the idea didn't get any traction. drivers/misc would already have been a nicer option imo. Not only that, but the whole vexpress-config code design is not the nicest piece of code I've ever seen. And I'm usually not picky. e.g. the whole vexpress-config ad-hoc API is awkward and I wonder if it could be implemented as a bus instead. Funny you mention this :-) Again, the first version actually was a vexpress-config bus. The feedback was - a whole bus_type is over the top (I'm simplifying the letter slightly but this was the spirit). I think it would make sense to have it under drivers/bus/. It might be a little over the top, but when I look at the current code I'd be really happy to read an over-the-top bus driver instead. At least we'd know straight away what youre trying to achieve with this code and it would probably remove a fair chunk of the weird bridge API (the registering and the function reference stuff). Do you have a reference for the patch first version ? FWIW I take the blame here for not reviewing the initial driver submission that Arnd kindly sent to me...But now that I'm looking at it, I think it really is on the edge of being staging material. Any thought on that ? I'm more than happy to improve it. The infrastructure (as in: the hardware) itself is slightly strange and the code pretty much reflects the situation. There is also a very good reason for some of the oddities like static bridges array etc - the infrastructure must be functional very early, long before slab is available (this also caused a lot of issues with the bus-based implementation, as the device model does kmalloc all over the place). So to summarize - I'm open to any suggestions and ready to spend time on this stuff. I'd say splitting the sysreg driver and leaving only the MFD bits in the MFD driver would be a first step. Also, re-considering the bus implementation for the config part would also be interesting. I'd be interested in looking at your first version of the patch. Regards and thanks for your time! Thanks for your understanding. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v3 0/2] drivers: mfd: Versatile Express SPC support
Morning, Samuel, On Tue, 2013-06-18 at 10:09 +0100, Samuel Ortiz wrote: Hi Pawell, Double l in the wrong place ;-) If you feel strongly about it, I'm ready to split it into mfd_cells and move the gpio and leds code into separate drivers, however I'm not convinced that it's worth the effort. Well, after seeing your last patch for ifdef'ing the GPIO and LED code, I think it is worth the effort. Good point. But as this - obviously - won't happen on time for 3.11, I hope you would be kind enough to take the #ifdef patch in for now. Now, as to the vexpress-config.c... The first time I've posted the series, all parts lived in driver/misc(/vexpress), but (if I remember correctly) Arnd had some feelings about misc existence at all... I was thinking about a separate directory for random system/platform/machine configuration drivers, but the idea didn't get any traction. drivers/misc would already have been a nicer option imo. Ok. Quite conveniently Arnd is the driver/misc maintainer so I'll get first-hand feedback on this. Not only that, but the whole vexpress-config code design is not the nicest piece of code I've ever seen. And I'm usually not picky. e.g. the whole vexpress-config ad-hoc API is awkward and I wonder if it could be implemented as a bus instead. Funny you mention this :-) Again, the first version actually was a vexpress-config bus. The feedback was - a whole bus_type is over the top (I'm simplifying the letter slightly but this was the spirit). I think it would make sense to have it under drivers/bus/. It might be a little over the top, but when I look at the current code I'd be really happy to read an over-the-top bus driver instead. At least we'd know straight away what youre trying to achieve with this code and it would probably remove a fair chunk of the weird bridge API (the registering and the function reference stuff). Do you have a reference for the patch first version ? http://thread.gmane.org/gmane.linux.ports.arm.kernel/185014/focus=185019 So to summarize - I'm open to any suggestions and ready to spend time on this stuff. I'd say splitting the sysreg driver and leaving only the MFD bits in the MFD driver would be a first step. Also, re-considering the bus implementation for the config part would also be interesting. Ok, so what I'll do: 1. Split vexpress-sysreg into * gpio driver * leds driver * the rest (still in mfd though) 2. Move the vexpress-sysreg platform management functions into misc (unless we get any better place for it) 3. Move vexpress-config into drivers/bus as it is (however I see no one in MAINTAINERS for this directory) 4. *Try* to use more of the standard bus (aka bus_type) infrastructure, however this will be the trickiest part of this all - as I've mentioned the code must be functional before SLAB is up... You shall see some patches before 3.11-rc1. Paweł ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v11 2/8] ARM: edma: Add DT and runtime PM support to the private EDMA API
On 6/18/2013 12:08 PM, Joel A Fernandes wrote:
From: Matt Porter mpor...@ti.com
Adds support for parsing the TI EDMA DT data into the required EDMA
private API platform data. Enables runtime PM support to initialize
the EDMA hwmod. Enables build on OMAP.
Changes by Joel:
* Setup default one-to-one mapping for queue_priority and queue_tc
mapping as discussed in [1].
* Split out xbar stuff to separate patch. [1]
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
---
arch/arm/common/edma.c | 190
+---
arch/arm/mach-omap2/Kconfig|1 +
include/linux/platform_data/edma.h |4 +-
3 files changed, 181 insertions(+), 14 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index a1db6cd..9823b79 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/slab.h
+#include linux/edma.h
+#include linux/err.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_dma.h
+#include linux/of_irq.h
+#include linux/pm_runtime.h
#include linux/platform_data/edma.h
@@ -1369,31 +1376,173 @@ void edma_clear_event(unsigned channel)
EXPORT_SYMBOL(edma_clear_event);
/*---*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+ const char *propname, s8 *out_values,
+ size_t sz)
+{
+ int ret;
+
+ ret = of_property_read_u8_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+ const char *propname, s16 *out_values,
+ size_t sz)
+{
+ int ret;
+
+ ret = of_property_read_u16_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
These functions dont get used here. Can you introduce them when you
actually need them?
-static int __init edma_probe(struct platform_device *pdev)
+static int edma_of_parse_dt(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata)
+{
+ int ret = 0, i;
+ u32 value;
+ struct property *prop;
+ size_t sz;
+ struct edma_rsv_info *rsv_info;
+ const s16 (*rsv_chans)[2], (*rsv_slots)[2];
rsv_slots is unused. You get an unused variable warning here. rsv_chans
is also unused.
+ s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ memset(pdata, 0, sizeof(struct edma_soc_info));
+
+ ret = of_property_read_u32(node, dma-channels, value);
+ if (ret 0)
+ return ret;
+ pdata-n_channel = value;
+
+ ret = of_property_read_u32(node, ti,edma-regions, value);
+ if (ret 0)
+ return ret;
+ pdata-n_region = value;
+
+ ret = of_property_read_u32(node, ti,edma-slots, value);
+ if (ret 0)
+ return ret;
+ pdata-n_slot = value;
+
+ pdata-n_cc = 1;
+ pdata-n_tc = 3;
n_tc is not used in the driver AFAICS. You can drop this line and also
possibly remove the platform data member as well.
+
+ rsv_info =
+ devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
+ if (!rsv_info)
+ return -ENOMEM;
+ pdata-rsv = rsv_info;
+
+ queue_tc_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
+ if (!queue_tc_map)
+ return -ENOMEM;
+
+ for (i = 0; i 3; i++)
+ queue_tc_map[i][0] = queue_tc_map[i][1] = i;
+ queue_tc_map[i][0] = queue_tc_map[i][1] = -1;
+
+ pdata-queue_tc_mapping = queue_tc_map;
+
+ queue_priority_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+
+ for (i = 0; i 3; i++)
+ queue_priority_map[i][0] = queue_priority_map[i][1] = i;
+ queue_priority_map[i][0] = queue_priority_map[i][1] = -1;
+
+ pdata-queue_priority_mapping = queue_priority_map;
+
+ pdata-default_queue = 0;
+
+
Extra empty line here.
+ return ret;
+}
Usage of devres APIs in this function is nice, but, there is no check
for return value of edma_of_parse_dt() in the probe down below. So in
effect it leaks memory on error.
+
+static struct of_dma_filter_info edma_filter_info = {
+ .filter_fn = edma_filter_fn,
+};
+
+static int edma_probe(struct platform_device
Re: [PATCH v7 1/9] drivers: phy: add generic PHY framework
Hi,
On Thu, Jun 13, 2013 at 02:13:51PM +0530, Kishon Vijay Abraham I wrote:
+struct phy_provider *of_phy_provider_register(struct device *dev,
+ struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+ struct of_phandle_args *args))
I would rename this to __of_phy_provider_register() and in a header
have:
#define of_phy_provider_register(dev, xlate)\
__of_phy_provider_register((dev), THIS_MODULE, (xlate))
then your users don't need to remember always passing THIS_MODULE
argument.
+struct phy_provider *devm_of_phy_provider_register(struct device *dev,
+ struct module *owner, struct phy * (*of_xlate)(struct device *dev,
+ struct of_phandle_args *args))
likewise.
+/**
+ * phy_release() - release the phy
+ * @dev: the dev member within phy
+ *
+ * When the last reference to the device is removed, it is called
+ * from the embedded kobject as release method.
+ */
+static void phy_release(struct device *dev)
+{
+ struct phy *phy;
+
+ phy = container_of(dev, struct phy, dev);
I would have a:
#define to_phy(dev) (container_of((dev), struct phy dev))
somewhere in a header, just for the sake of brevity :-p
+ dev_dbg(dev, releasing '%s'\n, dev_name(dev));
make it dev_vdbg() instead.
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
new file mode 100644
index 000..df0c98a
--- /dev/null
+++ b/include/linux/phy/phy.h
[ ... ]
+static inline int phy_init(struct phy *phy)
+{
+ int ret = -ENOTSUPP;
+
+ if (!pm_runtime_enabled(phy-dev))
+ goto no_pm_runtime;
+
+ ret = pm_runtime_get_sync(phy-dev);
+ if (ret 0) {
+ dev_err(phy-dev, get sync failed: %d\n, ret);
+ return ret;
+ }
+
+no_pm_runtime:
you can avoid this goto if you code as below, note that I'm also solving
a possible unbalanced PM runtime call which would prevent actual
*runtime* suspend of the PHY:
ret = phy_pm_runtime_get_sync(phy);
if (ret 0 ret != -ENOTSUPP)
return ret;
if (phy-ops-init) {
ret = phy-ops-init(phy);
if (ret 0) {
dev_err(phy-dev, failed to initialize -- %d\n,
ret);
goto out;
}
}
out:
/*
* In order to avoid unbalanced PM runtime calls, let's make
* sure to disable what we might have enabled when entering this
* function.
*/
phy_pm_runtime_put(phy);
return ret;
+}
+
+static inline int phy_exit(struct phy *phy)
+{
+ int ret = -ENOTSUPP;
+
+ if (phy-ops-exit)
+ ret = phy-ops-exit(phy);
+
+ if (!pm_runtime_enabled(phy-dev))
+ goto no_pm_runtime;
+
+ ret = pm_runtime_put_sync(phy-dev);
move your pm runtime wrappers before these calls and you can use them.
--
balbi
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 2/9] usb: phy: omap-usb2: use the new generic PHY framework
Hi, On Thu, Jun 13, 2013 at 02:13:52PM +0530, Kishon Vijay Abraham I wrote: @@ -159,6 +191,12 @@ static int omap_usb2_probe(struct platform_device *pdev) otg-start_srp = omap_usb_start_srp; otg-phy= phy-phy; + pm_runtime_enable(phy-dev); enabling pm_runtime here has the potential to cause a real big problem. How have you tested this patch ? -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 3/9] usb: phy: twl4030: use the new generic PHY framework
On Thu, Jun 13, 2013 at 02:13:53PM +0530, Kishon Vijay Abraham I wrote: Used the generic PHY framework API to create the PHY. For powering on and powering off the PHY, power_on and power_off ops are used. Once the MUSB OMAP glue is adapted to the new framework, the suspend and resume ops of usb phy library will be removed. However using the old usb phy library cannot be completely removed because otg is intertwined with phy and moving to the new framework completely will break otg. Once we have a separate otg state machine, we can get rid of the usb phy library. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 4/9] usb: phy: twl4030: twl4030 shouldn't be subsys_initcall
On Thu, Jun 13, 2013 at 02:13:54PM +0530, Kishon Vijay Abraham I wrote: Changed the inticall from subsys_initcall to module_init for twl4030-usb. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com not part of the series, should be sent separately. I'll queue this one for v3.12 once v3.11-rc1 is tagged. -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 5/9] ARM: OMAP: USB: Add phy binding information
On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote: In order for controllers to get PHY in case of non dt boot, the phy binding information (phy device name) should be added in the platform data of the controller. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com I would rather not pass strings around, any other way to handle this ? Why do you need to pass this string ? -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 6/9] ARM: dts: omap: update usb_otg_hs data
On Thu, Jun 13, 2013 at 02:13:56PM +0530, Kishon Vijay Abraham I wrote: Updated the usb_otg_hs dt data to include the *phy* and *phy-names* binding in order for the driver to use the new generic PHY framework. Also updated the Documentation to include the binding information. The PHY binding information can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 8/9] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
On Thu, Jun 13, 2013 at 02:13:58PM +0530, Kishon Vijay Abraham I wrote: Now that omap-usb2 is adapted to the new generic PHY framework, *set_suspend* ops can be removed from omap-usb2 driver. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 9/9] usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops
On Thu, Jun 13, 2013 at 02:13:59PM +0530, Kishon Vijay Abraham I wrote: Now that twl4030-usb is adapted to the new generic PHY framework, *set_suspend* and *phy_init* ops can be removed from twl4030-usb driver. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 7/9] usb: musb: omap2430: use the new generic PHY framework
Hi,
On Thu, Jun 13, 2013 at 02:13:57PM +0530, Kishon Vijay Abraham I wrote:
Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on/get_sync and
power_off/put_sync to align with the new PHY framework.
musb-xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/musb_core.c |1 +
drivers/usb/musb/musb_core.h |3 +++
drivers/usb/musb/omap2430.c | 29 +
3 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 37a261a..f732bcc 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1864,6 +1864,7 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
musb-board_set_power = plat-set_power;
musb-min_power = plat-min_power;
musb-ops = plat-platform_ops;
+ musb-phy_label = plat-phy_label;
/* The musb_platform_init() call:
* - adjusts musb-mregs
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..498ae21 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
#include linux/usb.h
#include linux/usb/otg.h
#include linux/usb/musb.h
+#include linux/phy/phy.h
struct musb;
struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
u16 int_tx;
struct usb_phy *xceiv;
+ struct phy *phy;
int nIrq;
unsignedirq_wake:1;
@@ -434,6 +436,7 @@ struct musb {
unsigneddouble_buffer_not_ok:1;
struct musb_hdrc_config *config;
+ const char *phy_label;
#ifdef MUSB_CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 628b93f..c62a004 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -348,14 +348,24 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- if (dev-parent-of_node)
+ if (dev-parent-of_node) {
+ musb-phy = devm_phy_get(dev-parent, usb2-phy);
+
+ /* We can't totally remove musb-xceiv as of now because
+ * musb core uses xceiv.state and xceiv.otg. Once we have
+ * a separate state machine to handle otg, these can be moved
+ * out of xceiv and then we can start using the generic PHY
+ * framework
+ */
musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
usb-phy, 0);
- else
+ } else {
musb-xceiv = devm_usb_get_phy_dev(dev, 0);
+ musb-phy = devm_phy_get(dev, musb-phy_label);
+ }
- if (IS_ERR(musb-xceiv)) {
- status = PTR_ERR(musb-xceiv);
+ if (IS_ERR(musb-xceiv) || IS_ERR(musb-phy)) {
+ status = PTR_ERR(musb-xceiv) | PTR_ERR(musb-phy);
if (status == -ENXIO)
return status;
@@ -397,9 +407,10 @@ static int omap2430_musb_init(struct musb *musb)
if (glue-status != OMAP_MUSB_UNKNOWN)
omap_musb_set_mailbox(glue);
- usb_phy_init(musb-xceiv);
+ phy_init(musb-phy);
pm_runtime_put_noidle(musb-controller);
+ phy_pm_runtime_put(musb-phy);
see, weird unbalanced calls :-)
Make it all explicit:
phy_pm_runtime_get_sync(phy);
phy_init(phy);
phy_pm_runtime_put(phy);
--
balbi
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 2/9] usb: phy: omap-usb2: use the new generic PHY framework
Hi, On Tuesday 18 June 2013 03:10 PM, Felipe Balbi wrote: Hi, On Thu, Jun 13, 2013 at 02:13:52PM +0530, Kishon Vijay Abraham I wrote: @@ -159,6 +191,12 @@ static int omap_usb2_probe(struct platform_device *pdev) otg-start_srp = omap_usb_start_srp; otg-phy = phy-phy; + pm_runtime_enable(phy-dev); enabling pm_runtime here has the potential to cause a real big problem. How have you tested this patch ? performed boot and enumeration testing. What issue do you expect here? Thanks Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 2/9] usb: phy: omap-usb2: use the new generic PHY framework
Hi, On Tue, Jun 18, 2013 at 03:19:03PM +0530, Kishon Vijay Abraham I wrote: Hi, On Tuesday 18 June 2013 03:10 PM, Felipe Balbi wrote: Hi, On Thu, Jun 13, 2013 at 02:13:52PM +0530, Kishon Vijay Abraham I wrote: @@ -159,6 +191,12 @@ static int omap_usb2_probe(struct platform_device *pdev) otg-start_srp = omap_usb_start_srp; otg-phy= phy-phy; + pm_runtime_enable(phy-dev); enabling pm_runtime here has the potential to cause a real big problem. How have you tested this patch ? performed boot and enumeration testing. What issue do you expect here? hint: look at drvdata usage around the driver. Where is it initialized ? Where is it used ? -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 0/9] Generic PHY Framework
Hi, On Mon, Jun 17, 2013 at 12:16:35PM +0200, Sylwester Nawrocki wrote: I have already used this API for our MIPI CSI-2/DSIM DPHYs driver, the RFC patch series can be found at [1]. Thanks, Sylwester [1] http://www.spinics.net/lists/arm-kernel/msg251666.html one comment to that series: let's make the phy names standardized, how about phy-exynos-video-mipi.c or phy-mipi-csi-dsim.c ? -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 2/9] usb: phy: omap-usb2: use the new generic PHY framework
Hi, On Tuesday 18 June 2013 03:20 PM, Felipe Balbi wrote: Hi, On Tue, Jun 18, 2013 at 03:19:03PM +0530, Kishon Vijay Abraham I wrote: Hi, On Tuesday 18 June 2013 03:10 PM, Felipe Balbi wrote: Hi, On Thu, Jun 13, 2013 at 02:13:52PM +0530, Kishon Vijay Abraham I wrote: @@ -159,6 +191,12 @@ static int omap_usb2_probe(struct platform_device *pdev) otg-start_srp = omap_usb_start_srp; otg-phy = phy-phy; + pm_runtime_enable(phy-dev); enabling pm_runtime here has the potential to cause a real big problem. How have you tested this patch ? performed boot and enumeration testing. What issue do you expect here? hint: look at drvdata usage around the driver. Where is it initialized ? Where is it used ? hmm.. since runtime_get calls weren't made very early, I think I dint see any issues. Thanks for pointing this. Thanks Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] [media] coda: fix missing unlock on error in coda_stop_streaming()
Am Dienstag, den 18.06.2013, 13:00 +0800 schrieb Wei Yongjun:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing unlock before return from function coda_stop_streaming()
in the error handling case.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/media/platform/coda.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index df4ada88..2c3cd17 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -1347,6 +1347,7 @@ static int coda_stop_streaming(struct vb2_queue *q)
if (coda_command_sync(ctx, CODA_COMMAND_SEQ_END)) {
v4l2_err(dev-v4l2_dev,
CODA_COMMAND_SEQ_END failed\n);
+ mutex_unlock(dev-coda_mutex);
return -ETIMEDOUT;
}
mutex_unlock(dev-coda_mutex);
Thanks! If you don't mind, I'll integrate this change into the [media]
coda: add CODA7541 decoding support for v2.
regards
Philipp
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 5/9] ARM: OMAP: USB: Add phy binding information
Hi, On Tuesday 18 June 2013 03:14 PM, Felipe Balbi wrote: On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote: In order for controllers to get PHY in case of non dt boot, the phy binding information (phy device name) should be added in the platform data of the controller. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com I would rather not pass strings around, any other way to handle this ? Why do you need to pass this string ? Our old way of binding the controller and the phy using device name started creating problems after the devices are created using PLATFORM_DEVID_AUTO. Infact non-dt boot is broken in mainline for OMAP3 platforms for which I have posted a RFC series http://www.serverphorums.com/read.php?12,708632 which also uses strings. I'm not sure of any other way to deal with this. Thanks Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v11 3/8] ARM: edma: Add EDMA crossbar event mux support
On 6/18/2013 12:08 PM, Joel A Fernandes wrote:
From: Matt Porter mpor...@ti.com
Changes by Joel:
* Split EDMA xbar support out of original EDMA DT parsing patch
to keep it easier for review.
* Rewrite shift and offset calculation.
Suggested-by: Sekhar Nori nsek...@ti.com
Suggested by: Andy Shevchenko andy.shevche...@gmail.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
Reference:
[1] https://patchwork.kernel.org/patch/2226991/
---
arch/arm/common/edma.c | 59
include/linux/platform_data/edma.h |1 +
2 files changed, 60 insertions(+)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 9823b79..1c2fb15 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1410,6 +1410,52 @@ static int edma_of_read_u32_to_s16_array(const struct
device_node *np,
return 0;
}
+static int edma_xbar_event_map(struct device *dev,
+struct device_node *node,
+struct edma_soc_info *pdata, int len)
+{
+ int ret = 0;
+ int i;
+ struct resource res;
+ void *xbar;
void __iomem *xbar;
+ const s16 (*xbar_chans)[2];
+ u32 shift, offset, mux;
+
+ xbar_chans = devm_kzalloc(dev,
+ len/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!xbar_chans)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(node, 1, res);
+ if (ret)
+ return -EIO;
+
+ xbar = devm_ioremap(dev, res.start, resource_size(res));
+ if (!xbar)
+ return -ENOMEM;
+
+ ret = edma_of_read_u32_to_s16_array(node,
+ ti,edma-xbar-event-map,
+ (s16 *)xbar_chans,
+ len/sizeof(u32));
+ if (ret)
+ return -EIO;
+
+ for (i = 0; xbar_chans[i][0] != -1; i++) {
+ shift = (xbar_chans[i][1] 0x03) 3;
+ offset = xbar_chans[i][1] 0xfffc;
+ mux = readl((void *)((u32)xbar + offset));
Please drop unnecessary casting. Simply:
mux = readl(xbar + offset);
+ mux = ~(0xff shift);
+ mux |= xbar_chans[i][0] shift;
+ writel(mux, (void *)((u32)xbar + offset));
Fix the writel likewise.
+ }
+
+ pdata-xbar_chans = xbar_chans;
+
+ return 0;
+}
+
static int edma_of_parse_dt(struct device *dev,
struct device_node *node,
struct edma_soc_info *pdata)
@@ -1470,6 +1516,9 @@ static int edma_of_parse_dt(struct device *dev,
pdata-default_queue = 0;
+ prop = of_find_property(node, ti,edma-xbar-event-map, sz);
+ if (prop)
+ ret = edma_xbar_event_map(dev, node, pdata, sz);
return ret;
}
@@ -1489,6 +1538,7 @@ static int edma_probe(struct platform_device *pdev)
int status = -1;
const s16 (*rsv_chans)[2];
const s16 (*rsv_slots)[2];
+ const s16 (*xbar_chans)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
struct resource *r[EDMA_MAX_CC] = {NULL, NULL};
@@ -1617,6 +1667,15 @@ static int edma_probe(struct platform_device *pdev)
}
}
+ /* Clear the xbar mapped channels in unused list */
+ xbar_chans = info[j]-xbar_chans;
+ if (xbar_chans) {
+ for (i = 0; xbar_chans[i][1] != -1; i++) {
+ off = xbar_chans[i][1];
+ clear_bits(off, 1,
+ edma_cc[j]-edma_unused);
Please fix the alignment here.
Thanks,
Sekhar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
Hi Olof,
thanks a lot.
On Mon, Jun 17, 2013 at 06:44:51PM +0100, Olof Johansson wrote:
On Mon, Jun 17, 2013 at 04:51:09PM +0100, Lorenzo Pieralisi wrote:
The TC2 versatile express core tile integrates a logic block that provides
the
interface between the dual cluster test-chip and the M3 microcontroller that
carries out power management. The logic block, called Serial Power
Controller
(SPC), contains several memory mapped registers to control among other
things
low-power states, operating points and reset control.
This patch provides a driver that enables run-time control of features
implemented by the SPC control logic.
The SPC control logic is required to be programmed very early in the boot
process to reset secondary CPUs on the TC2 testchip, set-up jump addresses
and
wake-up IRQs for power management.
Since the SPC logic is also used to control clocks and operating points,
that have to be initialized early as well, the SPC interface consumers can
not
rely on early initcalls ordering, which is inconsistent, to wait for SPC
initialization. Hence, in order to keep the components relying on the SPC
coded in a sane way, the driver puts in place a synchronization scheme that
allows kernel drivers to check if the SPC driver has been initialized and if
not, to initialize it upon check.
A status variable is kept in memory so that loadable modules that require
SPC
interface (eg CPUfreq drivers) can still check the correct initialization
and
use the driver correctly after functions used at boot to init the driver are
freed.
The driver also provides a bridge interface through the vexpress config
infrastructure. Operations allowing to read/write operating points are
made to go via the same interface as configuration transactions so that
all requests to M3 are serialized.
Device tree bindings documentation for the SPC component is provided with
the patchset.
Sorry, I got to think of this over the weekend and should have replied
before you had a chance to repost, but still:
Why is the operating point and frequency change code in this driver at all?
Usually, the MFD driver contains a shared method to access register space on
a multifunction device, but the actual operation of each subdevice is handled
by individual drivers in the regular locations.
So, in the case of operating points and requencies, that should be in
a cpufreq driver. And the clock setup should presumably be in a clk
framework driver if needed.
Well, yes this can be done. I will probably move this code out of mfd
since this choice caused more issues than the current driver solves.
By moving the frequency changes into subsystems, we are certainly
trimming down the code, not sure we improve the maintainability though,
keep in mind that we already had to change the vexpress-config interface
to cope with SPC oddities, at least now these intricacies are self-contained.
What you are suggesting makes sense though, I will do it.
Then all that would be left here is the functionality for submitting the two
kinds of commands, and handling interrupts.
Not really. There are still a bunch of registers to set-up wake-up IRQs,
power down flags and warm-boot jump addresses that do not go through the
vexpress interface, they are ad-hoc. I could also split that stuff, but I
really do not think it is worth the effort.
That'll trim down the driver to a point where I think you'll find it much
easier to get merged. :-)
To start with I have to understand in which directory this code should
live. Moving the frequency settings in clk/CPUfreq drivers should be
feasible with extra DT complexity for their bindings.
[...]
+struct ve_spc_drvdata {
+ void __iomem *baseaddr;
+ /* A15 processor MPIDR[15:8] bitfield */
A comment describing what the meaning is would be more useful, even if
less technically specific. Or maybe something like Cluster ID of the
A15 cluster, from MPIDR[15:8] or similar.
+ u32 a15_clusid;
(I reserve the right to have more comments later but I think we want to
discuss
the removal of frequency management code first. :-)
I will do that and comments are always welcome.
Thanks,
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
On Tue, Jun 18, 2013 at 05:25:22AM +0100, Nicolas Pitre wrote:
On Mon, 17 Jun 2013, Lorenzo Pieralisi wrote:
The TC2 versatile express core tile integrates a logic block that provides
the
interface between the dual cluster test-chip and the M3 microcontroller that
carries out power management. The logic block, called Serial Power
Controller
(SPC), contains several memory mapped registers to control among other
things
low-power states, operating points and reset control.
[...]
I slightly modified the following before committing this patch to my TC2
branch:
+/**
+ * ve_spc_cpu_wakeup_irq()
+ *
+ * Function to set/clear per-CPU wake-up IRQs. Not protected by locking
since
+ * it might be used in code paths where normal cacheable locks are not
+ * working. Locking must be provided by the caller to ensure atomicity.
+ *
+ * @cpu: mpidr[7:0] bitfield describing cpu affinity level
+ * @cluster: mpidr[15:8] bitfield describing cluster affinity level
+ * @set: if true, wake-up IRQs are set, if false they are cleared
+ */
+void ve_spc_cpu_wakeup_irq(u32 cpu, u32 cluster, bool set)
+{
I made cluster first then cpu. All the other functions have the cluster
argument first, and ve_spc_set_resume_addr() already uses that order.
Ok thanks.
[...]
+#ifdef CONFIG_VEXPRESS_SPC
+int ve_spc_probe(void);
+int ve_spc_get_freq(u32 cluster);
+int ve_spc_set_freq(u32 cluster, u32 freq);
+int ve_spc_get_freq_table(u32 cluster, const u32 **fptr);
+void ve_spc_global_wakeup_irq(bool set);
+void ve_spc_cpu_wakeup_irq(u32 cpu, u32 cluster, bool set);
+void ve_spc_set_resume_addr(u32 cluster, u32 cpu, u32 addr);
+u32 ve_spc_get_nr_cpus(u32 cluster);
+void ve_spc_powerdown(u32 cluster, bool enable);
+#else
+static inline bool ve_spc_probe(void) { return -ENODEV; }
s/bool/int/
Bah, sorry.
Thanks a lot,
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 5/9] ARM: OMAP: USB: Add phy binding information
Hi, On Tue, Jun 18, 2013 at 03:34:36PM +0530, Kishon Vijay Abraham I wrote: On Tuesday 18 June 2013 03:14 PM, Felipe Balbi wrote: On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote: In order for controllers to get PHY in case of non dt boot, the phy binding information (phy device name) should be added in the platform data of the controller. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com I would rather not pass strings around, any other way to handle this ? Why do you need to pass this string ? Our old way of binding the controller and the phy using device name started creating problems after the devices are created using PLATFORM_DEVID_AUTO. Infact non-dt boot is broken in mainline for OMAP3 platforms for which I have posted a RFC series http://www.serverphorums.com/read.php?12,708632 which also uses strings. I'm not sure of any other way to deal with this. have you checked how other frameworks handle it ? Regulator has some sort of binding in board-files, but I guess it passes the regulator name? -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH REBASE] i2c-designware: make SDA hold time configurable
On Mon, Jun 17, 2013 at 11:55 PM, Rob Herring robherri...@gmail.com wrote: +Optional properties : + - sda-hold-time : should contain the SDA hold time in nanoseconds. Please specify time units in the property name. Perhaps i2c-sda-hold-time-ns. Based on reading the discussion, there is one similar property I have found: samsung,i2c-sda-delay = 100. I wouldn't copy it as it doesn't tell the units or what the delay is. Often on of the painful issues with DT models is the absence of the properties. Should someone create the property definition first under Documentation and _then_ patch everything around? (Though I think better to think and create documents first and after program accordingly) -- With Best Regards, Andy Shevchenko ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/4] ARM: dts: Add LCD and PWM support for exynos4210-origen
Ping Kukjin. On 11 June 2013 11:59, Sachin Kamat sachin.ka...@linaro.org wrote: This series is based on for-next branch of Kukjin's tree. Tested on Origen board. Changes since v1: * Split LCD patch into LCD and PWM as suggested by Tomasz Figa. * Added all PWM output nodes to pinctrl dtsi file. Sachin Kamat (3): ARM: dts: exynos4210: Add PWM related pinctrl entries ARM: dts: exynos4210: Add LCD related pinctrl entries ARM: dts: Add FIMD node to Origen4210 board Tushar Behera (1): ARM: dts: Set BUCK7 as always on for Origen board arch/arm/boot/dts/exynos4210-origen.dts | 22 +++ arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 89 + 2 files changed, 111 insertions(+) -- 1.7.9.5 -- With warm regards, Sachin ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/4] ARM: dts: omap5-uevm: Provide USB Host PHY clock frequency
USB Host PHY clock on port 2 must be configured to 19.2MHz.
Provide this information.
CC: Sricharan R r.sricha...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..c0ad472 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -40,6 +40,13 @@
hsusb2_phy: hsusb2_phy {
compatible = usb-nop-xceiv;
reset-supply = hsusb2_reset;
+ /**
+ * FIXME
+ * Put the right clock phandle here when available
+ * clocks = auxclk1;
+ * clock-names = main_clk;
+ */
+ clock-frequency = 1920;
};
/* HS USB Port 3 RESET */
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/4] ARM: OMAP4: Panda USB Host support and DVI EDID fix
Hi Benoit Tony, The first two patches make changes to dts files to get USB host support and DVI EDID to work on Panda. The third patch should get USB host functional on uEVM. The fourth patch is a temporary workaround to create a clock alias to the USB PHY clock as it is not possible to define this via device tree. This patch is required for USB host to work on Panda and uEVM. The first 3 patches are for Benoit and the last one is for Tony. cheers, -roger Roger Quadros (4): ARM: dts: omap4-panda: Add USB Host support ARM: dts: omap4-panda: Fix DVI EDID reads ARM: dts: omap5-uevm: Provide USB Host PHY clock frequency ARM: OMAP2+: dts: HACK: Provide alias to USB PHY clock arch/arm/boot/dts/omap4-panda-common.dtsi | 67 + arch/arm/boot/dts/omap5-uevm.dts |7 +++ arch/arm/mach-omap2/board-generic.c | 23 +- 3 files changed, 96 insertions(+), 1 deletions(-) -- 1.7.4.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/4] ARM: dts: omap4-panda: Add USB Host support
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62 +
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+ /* HS USB Port 1 RESET */
+ hsusb1_reset: hsusb1_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio2 30 0; /* gpio_62 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 1 Power */
+ hsusb1_power: hsusb1_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio1 1 0;/* gpio_1 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 1 */
+ hsusb1_phy: hsusb1_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb1_reset;
+ vcc-supply = hsusb1_power;
+ /**
+* FIXME:
+* put the right clock phandle here when available
+* clocks = auxclk3;
+* clock-names = main_clk;
+*/
+ clock-frequency = 1920;
+ };
};
omap4_pmx_wkup {
@@ -83,6 +119,7 @@
mcbsp1_pins
dss_hdmi_pins
tpd12s015_pins
+ hsusbb1_pins
;
twl6030_pins: pinmux_twl6030_pins {
@@ -133,6 +170,23 @@
;
};
+ hsusbb1_pins: pinmux_hsusbb1_pins {
+ pinctrl-single,pins =
+ 0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_clk.usbb1_ulpiphy_clk */
+ 0x84 (PIN_OUTPUT | MUX_MODE4) /*
usbb1_ulpitll_stp.usbb1_ulpiphy_stp */
+ 0x86 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dir.usbb1_ulpiphy_dir */
+ 0x88 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt */
+ 0x8a (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 */
+ 0x8c (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 */
+ 0x8e (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2 */
+ 0x90 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3 */
+ 0x92 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4 */
+ 0x94 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5 */
+ 0x96 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6 */
+ 0x98 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7 */
+ ;
+ };
+
i2c1_pins: pinmux_i2c1_pins {
pinctrl-single,pins =
0xe2 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c1_scl */
@@ -283,3 +337,11 @@
mode = 3;
power = 50;
};
+
+usbhshost {
+ port1-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = hsusb1_phy;
+};
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/4] ARM: dts: omap4-panda: Fix DVI EDID reads
On Panda the +5V supply for DVI EDID is supplied by the same regulator that poweres the USB Hub. Currently, the DSS/DVI subsystem doesn't know how to manage this regulator and so DVI EDID reads will fail if USB Hub is not enabled. As a temporary fix we keep this regulator permanently enabled on boot. This fixes the DVI EDID read problem. CC: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/omap4-panda-common.dtsi |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 7a21e8e..40df79e 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -80,6 +80,11 @@ gpio = gpio1 1 0;/* gpio_1 */ startup-delay-us = 7; enable-active-high; + /* +* FIXME: Remove boot-on when DSS can handle this regulator +* for DVI EDID. +*/ + regulator-boot-on; }; /* HS USB Host PHY on PORT 1 */ -- 1.7.4.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/4] ARM: OMAP2+: dts: HACK: Provide alias to USB PHY clock
Till the OMAP clocks are correctly defined in device tree, use
this temporary hack to provide clock alias to the USB PHY clocks.
Without this, USB Host Ethernet will not be functional with
device tree boots on Panda and uEVM.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 23 ++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 88aa6b1..2b2d0de 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,7 @@
#include linux/of_irq.h
#include linux/of_platform.h
#include linux/irqdomain.h
+#include linux/clk.h
#include asm/mach/arch.h
@@ -35,6 +36,21 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
{ }
};
+/*
+ * HACK: create alias for USB host PHY clock.
+ * Remove this when clock phandle can be provided via DT
+ */
+static void __init legacy_init_ehci_clk(char *clkname)
+{
+ int ret;
+
+ ret = clk_add_alias(main_clk, NULL, clkname, NULL);
+ if (ret) {
+ pr_err(%s:Failed to add main_clk alias to %s :%d\n,
+ __func__, clkname, ret);
+ }
+}
+
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
@@ -45,10 +61,15 @@ static void __init omap_generic_init(void)
* HACK: call display setup code for selected boards to enable omapdss.
* This will be removed when omapdss supports DT.
*/
- if (of_machine_is_compatible(ti,omap4-panda))
+ if (of_machine_is_compatible(ti,omap4-panda)) {
omap4_panda_display_init_of();
+ legacy_init_ehci_clk(auxclk3_ck);
+
+ }
else if (of_machine_is_compatible(ti,omap4-sdp))
omap_4430sdp_display_init_of();
+ else if (of_machine_is_compatible(ti,omap5-uevm))
+ legacy_init_ehci_clk(auxclk1_ck);
}
#ifdef CONFIG_SOC_OMAP2420
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 5/9] ARM: OMAP: USB: Add phy binding information
Hi, On Tuesday 18 June 2013 03:57 PM, Felipe Balbi wrote: Hi, On Tue, Jun 18, 2013 at 03:34:36PM +0530, Kishon Vijay Abraham I wrote: On Tuesday 18 June 2013 03:14 PM, Felipe Balbi wrote: On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote: In order for controllers to get PHY in case of non dt boot, the phy binding information (phy device name) should be added in the platform data of the controller. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com I would rather not pass strings around, any other way to handle this ? Why do you need to pass this string ? Our old way of binding the controller and the phy using device name started creating problems after the devices are created using PLATFORM_DEVID_AUTO. Infact non-dt boot is broken in mainline for OMAP3 platforms for which I have posted a RFC series http://www.serverphorums.com/read.php?12,708632 which also uses strings. I'm not sure of any other way to deal with this. have you checked how other frameworks handle it ? Regulator has some sort of binding in board-files, but I guess it passes the regulator name? From whatever I could make of, regulator has 3 ways to get the regulator one of which is using the binding in board-files (but it also uses device name which could create the same problem that we are facing). 1.) from dt data 2.) from _supply_ name 3.) from binding in board file (referred regulator_dev_lookup() in regulator/core.c) Thanks Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] ARM: OMAP2+: dts: HACK: Provide alias to USB PHY clock
* Roger Quadros rog...@ti.com [130618 04:17]:
Till the OMAP clocks are correctly defined in device tree, use
this temporary hack to provide clock alias to the USB PHY clocks.
Without this, USB Host Ethernet will not be functional with
device tree boots on Panda and uEVM.
Thanks, this looks OK to me to have USB working until we have the
DT defined clock patches ready.
The $Subject needs updating though, just make it ARM: OMAP2+: and
leave out the dts and hack from there.
Regards,
Tony
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 23 ++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 88aa6b1..2b2d0de 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,7 @@
#include linux/of_irq.h
#include linux/of_platform.h
#include linux/irqdomain.h
+#include linux/clk.h
#include asm/mach/arch.h
@@ -35,6 +36,21 @@ static struct of_device_id omap_dt_match_table[]
__initdata = {
{ }
};
+/*
+ * HACK: create alias for USB host PHY clock.
+ * Remove this when clock phandle can be provided via DT
+ */
+static void __init legacy_init_ehci_clk(char *clkname)
+{
+ int ret;
+
+ ret = clk_add_alias(main_clk, NULL, clkname, NULL);
+ if (ret) {
+ pr_err(%s:Failed to add main_clk alias to %s :%d\n,
+ __func__, clkname, ret);
+ }
+}
+
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
@@ -45,10 +61,15 @@ static void __init omap_generic_init(void)
* HACK: call display setup code for selected boards to enable omapdss.
* This will be removed when omapdss supports DT.
*/
- if (of_machine_is_compatible(ti,omap4-panda))
+ if (of_machine_is_compatible(ti,omap4-panda)) {
omap4_panda_display_init_of();
+ legacy_init_ehci_clk(auxclk3_ck);
+
+ }
else if (of_machine_is_compatible(ti,omap4-sdp))
omap_4430sdp_display_init_of();
+ else if (of_machine_is_compatible(ti,omap5-uevm))
+ legacy_init_ehci_clk(auxclk1_ck);
}
#ifdef CONFIG_SOC_OMAP2420
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 04/12] ARM: mvebu: Initialize MBus using the DT binding
Now that the mbus device tree binding has been introduced, we can
switch over to it.
Also, and since the initialization of the mbus driver is quite
fundamental for the system to work properly, this patch adds a BUG()
in case mbus fails to initialize.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-mvebu/armada-370-xp.c | 34 +-
1 file changed, 1 insertion(+), 33 deletions(-)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c
b/arch/arm/mach-mvebu/armada-370-xp.c
index 0dbc370..4c312be 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -34,44 +34,12 @@ static void __init armada_370_xp_map_io(void)
debug_ll_io_init();
}
-/*
- * This initialization will be replaced by a DT-based
- * initialization once the mvebu-mbus driver gains DT support.
- */
-
-#define ARMADA_370_XP_MBUS_WINS_OFFS 0x2
-#define ARMADA_370_XP_MBUS_WINS_SIZE 0x100
-#define ARMADA_370_XP_SDRAM_WINS_OFFS 0x20180
-#define ARMADA_370_XP_SDRAM_WINS_SIZE 0x20
-
-static void __init armada_370_xp_mbus_init(void)
-{
- char *mbus_soc_name;
- struct device_node *dn;
- const __be32 mbus_wins_offs = cpu_to_be32(ARMADA_370_XP_MBUS_WINS_OFFS);
- const __be32 sdram_wins_offs =
cpu_to_be32(ARMADA_370_XP_SDRAM_WINS_OFFS);
-
- if (of_machine_is_compatible(marvell,armada370))
- mbus_soc_name = marvell,armada370-mbus;
- else
- mbus_soc_name = marvell,armadaxp-mbus;
-
- dn = of_find_node_by_name(NULL, internal-regs);
- BUG_ON(!dn);
-
- mvebu_mbus_init(mbus_soc_name,
- of_translate_address(dn, mbus_wins_offs),
- ARMADA_370_XP_MBUS_WINS_SIZE,
- of_translate_address(dn, sdram_wins_offs),
- ARMADA_370_XP_SDRAM_WINS_SIZE);
-}
-
static void __init armada_370_xp_timer_and_clk_init(void)
{
mvebu_clocks_init();
armada_370_xp_timer_init();
coherency_init();
- armada_370_xp_mbus_init();
+ BUG_ON(mvebu_mbus_dt_init());
#ifdef CONFIG_CACHE_L2X0
l2x0_of_init(0, ~0UL);
#endif
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 03/12] bus: mvebu-mbus: Add static window allocation to the DT binding
This patch adds static window allocation to the device tree binding.
Each first-child of the mbus-compatible node, with a suitable 'ranges'
property, declaring an address translation, will trigger an address
decoding window allocation.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
.../devicetree/bindings/bus/mvebu-mbus.txt | 168 +
drivers/bus/mvebu-mbus.c | 121 ++-
2 files changed, 288 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/bus/mvebu-mbus.txt
diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
new file mode 100644
index 000..e15c280
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -0,0 +1,168 @@
+
+* Marvell MBus controller
+
+Required properties:
+
+- compatible: Should be set to one of the following:
+marvell,armada370-mbus
+marvell,armadaxp-mbus
+
+- reg: Device's register space.
+Two entries are expected, see the examples below.
+The first one controls the devices decoding window and
+the second one controls the SDRAM decoding window.
+
+- address-cells: Must be '2'. The first cell for the MBus ID encoding,
+ the second cell for the address offset within the window.
+
+- size-cells:Must be '1'.
+
+- ranges:Must be set up to provide a proper translation for each child.
+See the examples below.
+
+Example:
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus;
+ reg = 0xd002 0x100, 0xd0020180 0x20;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
+
+** MBus child device specification
+
+Each child device needs at least a 'ranges' property. If the child is avaiable
+(i.e. status not 'disabled'), then the MBus driver creates a decoding window
+for it. For instance, in the example below the BootROM child is specified:
+
+ soc {
+ compatible = marvell,armada370-mbus, simple-bus;
+ reg = 0xd002 0x100, 0xd0020180 0x20;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ ranges = ... /* other entries */
+ 0x011d 0 0 0xfff0 0x10;
+
+ bootrom {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 0x011d 0 0x10;
+ };
+
+ /* other children */
+ ...
+ };
+
+In the shown example, the MBus child node together with the translation
+entry in the 'ranges' property is what makes the MBus driver creates
+a static decoding window for the given child device.
+
+Since each window is identified by its target ID and attribute ID there's
+a special macro that can be use to simplify the translation entries:
+
+#define MBUS_ID(target,attributes) (((target) 24) | ((attributes) 16))
+
+Using this macro, the bootrom child node can be written in a slightly
+more readable fashion:
+
+ bootrom {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 MBUS_ID(0x01, 0x1d) 0 0x10;
+ };
+
+** About the target ID and attribute encodig
+
+As stated above, for each mbus-node first-level child, the MBus driver will
+allocate a decoding window. The window target ID and attribute is created
+using the first cell, which must have the following format:
+
+IIAA
+
+Where:
+ -- I = Marvell defined target ID for programmable windows
+ -- A = Marvell defined target attributes for programmable windows
+
+Valid windows are required to define the lower bytes as zero.
+Entries that do not correspond to valid windows, and must be skipped by
+the MBus driver, set a non-zero value in the lower bytes.
+
+** About the window base address
+
+Remember the MBus controller allows a great deal of flexibility for choosing
+the decoding window base address. When planning the device tree layout it's
+possible to choose any address as the base address, provided of course there's
+a region large enough available, and with the required alignment.
+
+Yet in other words: there's nothing preventing us from setting a base address
+of 0xf000, or 0xd000 for the NOR device shown above, if such region is
+unused.
+
+** Example
+
+See the example below, where a more complete device tree is shown:
+
+ soc {
+ compatible = marvell,armadaxp-mbus;
+ reg = 0 0xd002 0 0x100, 0 0xd0020180 0 0x20;
+
+ ranges = 0x0001 0 0 0xd000 0x10 /* internal-regs
*/
+ 0x0002 0 0 0xe000 0x810 /* pcie */
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
+ MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x800;
+
+
[PATCH v3 01/12] bus: mvebu-mbus: Factor out initialization details
We introduce a common initialization function mvebu_mbus_common_init()
that will be used by both legacy and device-tree initialization code.
This patch is an intermediate step, which will allow to introduce the
DT binding for this driver in a less intrusive way.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/bus/mvebu-mbus.c | 47 ++-
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 33c6947..d0feee5 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -830,26 +830,14 @@ static __init int mvebu_mbus_debugfs_init(void)
}
fs_initcall(mvebu_mbus_debugfs_init);
-int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
- size_t mbuswins_size,
- phys_addr_t sdramwins_phys_base,
- size_t sdramwins_size)
+static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
+phys_addr_t mbuswins_phys_base,
+size_t mbuswins_size,
+phys_addr_t sdramwins_phys_base,
+size_t sdramwins_size)
{
- struct mvebu_mbus_state *mbus = mbus_state;
- const struct of_device_id *of_id;
int win;
- for (of_id = of_mvebu_mbus_ids; of_id-compatible; of_id++)
- if (!strcmp(of_id-compatible, soc))
- break;
-
- if (!of_id-compatible) {
- pr_err(could not find a matching SoC family\n);
- return -ENODEV;
- }
-
- mbus-soc = of_id-data;
-
mbus-mbuswins_base = ioremap(mbuswins_phys_base, mbuswins_size);
if (!mbus-mbuswins_base)
return -ENOMEM;
@@ -870,3 +858,28 @@ int __init mvebu_mbus_init(const char *soc, phys_addr_t
mbuswins_phys_base,
return 0;
}
+
+int __init mvebu_mbus_init(const char *soc, phys_addr_t mbuswins_phys_base,
+ size_t mbuswins_size,
+ phys_addr_t sdramwins_phys_base,
+ size_t sdramwins_size)
+{
+ const struct of_device_id *of_id;
+
+ for (of_id = of_mvebu_mbus_ids; of_id-compatible; of_id++)
+ if (!strcmp(of_id-compatible, soc))
+ break;
+
+ if (!of_id-compatible) {
+ pr_err(could not find a matching SoC family\n);
+ return -ENODEV;
+ }
+
+ mbus_state.soc = of_id-data;
+
+ return mvebu_mbus_common_init(mbus_state,
+ mbuswins_phys_base,
+ mbuswins_size,
+ sdramwins_phys_base,
+ sdramwins_size);
+}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 06/12] memory: mvebu-devbus: Remove address decoding window workaround
Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/memory/mvebu-devbus.c | 64 ++-
1 file changed, 2 insertions(+), 62 deletions(-)
diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
index 978e8e3..94c9248 100644
--- a/drivers/memory/mvebu-devbus.c
+++ b/drivers/memory/mvebu-devbus.c
@@ -208,16 +208,11 @@ static int mvebu_devbus_probe(struct platform_device
*pdev)
{
struct device *dev = pdev-dev;
struct device_node *node = pdev-dev.of_node;
- struct device_node *parent;
struct devbus *devbus;
struct resource *res;
struct clk *clk;
unsigned long rate;
- const __be32 *ranges;
- int err, cs;
- int addr_cells, p_addr_cells, size_cells;
- int ranges_len, tuple_len;
- u32 base, size;
+ int err;
devbus = devm_kzalloc(pdev-dev, sizeof(struct devbus), GFP_KERNEL);
if (!devbus)
@@ -248,68 +243,13 @@ static int mvebu_devbus_probe(struct platform_device
*pdev)
return err;
/*
-* Allocate an address window for this device.
-* If the device probing fails, then we won't be able to
-* remove the allocated address decoding window.
-*
-* FIXME: This is only a temporary hack! We need to do this here
-* because we still don't have device tree bindings for mbus.
-* Once that support is added, we will declare these address windows
-* statically in the device tree, and remove the window configuration
-* from here.
-*/
-
- /*
-* Get the CS to choose the window string.
-* This is a bit hacky, but it will be removed once the
-* address windows are declared in the device tree.
-*/
- cs = (((unsigned long)devbus-base) % 0x400) / 8;
-
- /*
-* Parse 'ranges' property to obtain a (base,size) window tuple.
-* This will be removed once the address windows
-* are declared in the device tree.
-*/
- parent = of_get_parent(node);
- if (!parent)
- return -EINVAL;
-
- p_addr_cells = of_n_addr_cells(parent);
- of_node_put(parent);
-
- addr_cells = of_n_addr_cells(node);
- size_cells = of_n_size_cells(node);
- tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
-
- ranges = of_get_property(node, ranges, ranges_len);
- if (ranges == NULL || ranges_len != tuple_len)
- return -EINVAL;
-
- base = of_translate_address(node, ranges + addr_cells);
- if (base == OF_BAD_ADDR)
- return -EINVAL;
- size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
-
- /*
-* Create an mbus address windows.
-* FIXME: Remove this, together with the above code, once the
-* address windows are declared in the device tree.
-*/
- err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
- if (err 0)
- return err;
-
- /*
* We need to create a child device explicitly from here to
* guarantee that the child will be probed after the timing
* parameters for the bus are written.
*/
err = of_platform_populate(node, NULL, NULL, dev);
- if (err 0) {
- mvebu_mbus_del_window(base, size);
+ if (err 0)
return err;
- }
return 0;
}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 09/12] ARM: mvebu: Add BootROM to Armada 370/XP device tree
In order to access the SoC BootROM, we need to declare a mapping
(through a ranges property). The mbus driver will use this property
to allocate a suitable address decoding window.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 3 ++-
arch/arm/boot/dts/armada-370-mirabox.dts | 3 ++-
arch/arm/boot/dts/armada-370-rd.dts | 3 ++-
arch/arm/boot/dts/armada-370-xp.dtsi | 2 ++
arch/arm/boot/dts/armada-370.dtsi| 6 ++
arch/arm/boot/dts/armada-xp-db.dts | 3 ++-
arch/arm/boot/dts/armada-xp-gp.dts | 3 ++-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 3 ++-
arch/arm/boot/dts/armada-xp.dtsi | 6 ++
9 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 530d1cf..c313968 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,7 +30,8 @@
};
soc {
- ranges = 0x0001 0 0xd000 0x10;
+ ranges = 0x0001 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index ad60835..abb1ccf 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,7 +25,8 @@
};
soc {
- ranges = 0x0001 0 0xd000 0x10;
+ ranges = 0x0001 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 9c2ab7f..9ae8bdc 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,7 +28,8 @@
};
soc {
- ranges = 0x0001 0 0xd000 0x10;
+ ranges = 0x0001 0 0xd000 0x10
+ MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 633534dd..4ae5eb5 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -16,6 +16,8 @@
* 370 and Armada XP SoC.
*/
+#define MBUS_ID(target,attributes) (((target) 24) | ((attributes) 16))
+
/include/ skeleton64.dtsi
/ {
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index c274b7b..c7f9971 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -32,6 +32,12 @@
compatible = marvell,armada370-mbus, simple-bus;
reg = 0xd002 0x100, 0xd0020180 0x20;
+ bootrom {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 MBUS_ID(0x01, 0xe0) 0 0x;
+ };
+
internal-regs {
system-controller@18200 {
compatible =
marvell,armada-370-xp-system-controller;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index 0996215..84e7ab2 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,7 +30,8 @@
};
soc {
- ranges = 0x0001 0 0 0xd000 0x10;
+ ranges = 0x0001 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index f095a3e..1f4daa7 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,7 +39,8 @@
};
soc {
- ranges = 0x0001 0 0 0xd000 0x10;
+ ranges = 0x0001 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
serial@12000 {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 91827cb..ea47196 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -27,7 +27,8 @@
};
soc {
- ranges = 0x0001 0 0 0xd000 0x10;
+ ranges = 0x0001 0 0 0xd000 0x10
+ MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
internal-regs {
[PATCH v3 07/12] ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 2 +-
arch/arm/boot/dts/armada-370-mirabox.dts | 2 +-
arch/arm/boot/dts/armada-370-rd.dts | 2 +-
arch/arm/boot/dts/armada-370.dtsi| 2 +-
arch/arm/boot/dts/armada-xp-db.dts | 2 +-
arch/arm/boot/dts/armada-xp-gp.dts | 2 +-
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 2 +-
arch/arm/boot/dts/armada-xp.dtsi | 2 +-
10 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 2353b1f..231f8b2 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Marvell Armada 370 Evaluation Board;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 14e36e1..7005f27 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -9,7 +9,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Globalscale Mirabox;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 130f839..5c3a1ec 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -12,7 +12,7 @@
*/
/dts-v1/;
-/include/ armada-370.dtsi
+#include armada-370.dtsi
/ {
model = Marvell Armada 370 Reference Design;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index fa3dfc6..08ec6e3 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -15,7 +15,7 @@
* common to all Armada SoCs.
*/
-/include/ armada-370-xp.dtsi
+#include armada-370-xp.dtsi
/include/ skeleton.dtsi
/ {
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index d6cc8bf..9a6ad0e 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78460.dtsi
+#include armada-xp-mv78460.dtsi
/ {
model = Marvell Armada XP Evaluation Board;
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 3ee63d1..e0c6f60 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -14,7 +14,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78460.dtsi
+#include armada-xp-mv78460.dtsi
/ {
model = Marvell Armada XP Development Board DB-MV784MP-GP;
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index f4029f0..c80c60e 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -13,7 +13,7 @@
* common to all Armada XP SoCs.
*/
-/include/ armada-xp.dtsi
+#include armada-xp.dtsi
/ {
model = Marvell Armada XP MV78260 SoC;
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 488ca5e..3874548 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -13,7 +13,7 @@
* common to all Armada XP SoCs.
*/
-/include/ armada-xp.dtsi
+#include armada-xp.dtsi
/ {
model = Marvell Armada XP MV78460 SoC;
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 46b7850..27a0ecf 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -11,7 +11,7 @@
*/
/dts-v1/;
-/include/ armada-xp-mv78260.dtsi
+#include armada-xp-mv78260.dtsi
/ {
model = PlatHome OpenBlocks AX3-4 board;
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 1ee8540..3e770db 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -16,7 +16,7 @@
* common to all Armada SoCs.
*/
-/include/ armada-370-xp.dtsi
+#include armada-370-xp.dtsi
/ {
model = Marvell Armada XP family SoC;
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 11/12] ARM: mvebu: Relocate Armada 370 PCIe device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 1 +
arch/arm/boot/dts/armada-370-mirabox.dts | 33 +--
arch/arm/boot/dts/armada-370-rd.dts | 1 +
arch/arm/boot/dts/armada-370.dtsi| 97
4 files changed, 68 insertions(+), 64 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index c313968..6891343 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -31,6 +31,7 @@
soc {
ranges = 0x0001 0 0xd000 0x10
+ 0x0002 0 0xe000 0x810
MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index abb1ccf..830727a 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -26,8 +26,25 @@
soc {
ranges = 0x0001 0 0xd000 0x10
+ 0x0002 0 0xe000 0x810
MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
+ pcie-controller {
+ status = okay;
+
+ /* Internal mini-PCIe connector */
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+
+ /* Connected on the PCB to a USB 3.0 XHCI controller */
+ pcie@2,0 {
+ /* Port 1, Lane 0 */
+ status = okay;
+ };
+ };
+
internal-regs {
serial@12000 {
clock-frequency = 2;
@@ -122,22 +139,6 @@
reg = 0x25;
};
};
-
- pcie-controller {
- status = okay;
-
- /* Internal mini-PCIe connector */
- pcie@1,0 {
- /* Port 0, Lane 0 */
- status = okay;
- };
-
- /* Connected on the PCB to a USB 3.0 XHCI
controller */
- pcie@2,0 {
- /* Port 1, Lane 0 */
- status = okay;
- };
- };
};
};
};
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 9ae8bdc..132cf8e 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -29,6 +29,7 @@
soc {
ranges = 0x0001 0 0xd000 0x10
+ 0x0002 0 0xe000 0x810
MBUS_ID(0x01, 0xe0) 0 0xfff0 0x10;
internal-regs {
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index c7f9971..1288a78 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -38,6 +38,55 @@
ranges = 0 MBUS_ID(0x01, 0xe0) 0 0x;
};
+ pcie-controller {
+ compatible = marvell,armada-370-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ ranges =
+ 0x8200 0 0x40x0001 0x4 0
0x2000
+ 0x8200 0 0x80x0001 0x8 0
0x2000
+ 0x8200 0 0xe000 0x0002 0 0
0x0800
+ 0x8100 0 0 0x0002 0x800 0
0x0010;
+
+ pcie@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0x4 0
0x2000;
+ reg = 0x0800 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+
[PATCH v3 08/12] ARM: mvebu: Add MBus to Armada 370/XP device tree
The Armada 370/XP SoC family has a completely configurable address
space handled by the MBus controller.
This patch introduces the device tree layout of MBus, making the
'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node,
this makes all of them sit behind the mbus, thus describing the
hardware accurately.
A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 2 ++
arch/arm/boot/dts/armada-370-mirabox.dts | 2 ++
arch/arm/boot/dts/armada-370-rd.dts | 2 ++
arch/arm/boot/dts/armada-370-xp.dtsi | 7 ++-
arch/arm/boot/dts/armada-370.dtsi| 5 +++--
arch/arm/boot/dts/armada-xp-db.dts | 2 ++
arch/arm/boot/dts/armada-xp-gp.dts | 3 +--
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 3 +--
arch/arm/boot/dts/armada-xp.dtsi | 3 +++
9 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 231f8b2..530d1cf 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,6 +30,8 @@
};
soc {
+ ranges = 0x0001 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 7005f27..ad60835 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,6 +25,8 @@
};
soc {
+ ranges = 0x0001 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 5c3a1ec..9c2ab7f 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,6 +28,8 @@
};
soc {
+ ranges = 0x0001 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 2;
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 52a1f5e..633534dd 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -29,18 +29,15 @@
};
soc {
- #address-cells = 1;
+ #address-cells = 2;
#size-cells = 1;
- compatible = simple-bus;
interrupt-parent = mpic;
- ranges = 0 0 0xd000 0x010 /* internal
registers */
- 0xe000 0 0xe000 0x810 /* PCIe */;
internal-regs {
compatible = simple-bus;
#address-cells = 1;
#size-cells = 1;
- ranges;
+ ranges = 0 0x0001 0 0x10;
mpic: interrupt-controller@2 {
compatible = marvell,mpic;
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 08ec6e3..c274b7b 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -29,8 +29,9 @@
};
soc {
- ranges = 0 0xd000 0x010 /* internal registers
*/
- 0xe000 0xe000 0x810 /* PCIe */;
+ compatible = marvell,armada370-mbus, simple-bus;
+ reg = 0xd002 0x100, 0xd0020180 0x20;
+
internal-regs {
system-controller@18200 {
compatible =
marvell,armada-370-xp-system-controller;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index 9a6ad0e..0996215 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -30,6 +30,8 @@
};
soc {
+ ranges = 0x0001 0 0 0xd000 0x10;
+
internal-regs {
serial@12000 {
clock-frequency = 25000;
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index e0c6f60..f095a3e 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -39,8 +39,7 @@
};
soc {
- ranges = 0 0 0xd000 0x10
- 0xf000 0 0xf000 0x100;
+ ranges =
[PATCH v3 10/12] ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the DeviceBus out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the hardware.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-370-xp.dtsi | 94 +---
arch/arm/boot/dts/armada-xp-gp.dts | 60 +++
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 60 +++
3 files changed, 110 insertions(+), 104 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 4ae5eb5..0cd23ac 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -35,6 +35,56 @@
#size-cells = 1;
interrupt-parent = mpic;
+ devbus-bootcs {
+ compatible = marvell,mvebu-devbus;
+ reg = 0x0001 0x10400 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x2f) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs0 {
+ compatible = marvell,mvebu-devbus;
+ reg = 0x0001 0x10408 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3e) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs1 {
+ compatible = marvell,mvebu-devbus;
+ reg = 0x0001 0x10410 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3d) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs2 {
+ compatible = marvell,mvebu-devbus;
+ reg = 0x0001 0x10418 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x3b) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
+ devbus-cs3 {
+ compatible = marvell,mvebu-devbus;
+ reg = 0x0001 0x10420 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x37) 0 0x;
+ #address-cells = 1;
+ #size-cells = 1;
+ clocks = coreclk 0;
+ status = disabled;
+ };
+
internal-regs {
compatible = simple-bus;
#address-cells = 1;
@@ -181,50 +231,6 @@
status = disabled;
};
- devbus-bootcs@10400 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10400 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs0@10408 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10408 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs1@10410 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10410 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs2@10418 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10418 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
- status = disabled;
- };
-
- devbus-cs3@10420 {
- compatible = marvell,mvebu-devbus;
- reg = 0x10420 0x8;
- #address-cells = 1;
- #size-cells = 1;
- clocks = coreclk 0;
-
[PATCH v3 12/12] ARM: mvebu: Relocate Armada XP PCIe device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-db.dts | 67 ++--
arch/arm/boot/dts/armada-xp-gp.dts | 43 +--
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 209 ++---
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 245 +++
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 377 ---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 19 +-
6 files changed, 483 insertions(+), 477 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index 84e7ab2..95babaf 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -31,8 +31,42 @@
soc {
ranges = 0x0001 0 0 0xd000 0x10
+ 0x0002 0 0 0xe000 0x810
MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10;
+ pcie-controller {
+ status = okay;
+
+ /*
+* All 6 slots are physically present as
+* standard PCIe slots on the board.
+*/
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+ pcie@2,0 {
+ /* Port 0, Lane 1 */
+ status = okay;
+ };
+ pcie@3,0 {
+ /* Port 0, Lane 2 */
+ status = okay;
+ };
+ pcie@4,0 {
+ /* Port 0, Lane 3 */
+ status = okay;
+ };
+ pcie@9,0 {
+ /* Port 2, Lane 0 */
+ status = okay;
+ };
+ pcie@10,0 {
+ /* Port 3, Lane 0 */
+ status = okay;
+ };
+ };
+
internal-regs {
serial@12000 {
clock-frequency = 25000;
@@ -125,39 +159,6 @@
spi-max-frequency = 2000;
};
};
-
- pcie-controller {
- status = okay;
-
- /*
-* All 6 slots are physically present as
-* standard PCIe slots on the board.
-*/
- pcie@1,0 {
- /* Port 0, Lane 0 */
- status = okay;
- };
- pcie@2,0 {
- /* Port 0, Lane 1 */
- status = okay;
- };
- pcie@3,0 {
- /* Port 0, Lane 2 */
- status = okay;
- };
- pcie@4,0 {
- /* Port 0, Lane 3 */
- status = okay;
- };
- pcie@9,0 {
- /* Port 2, Lane 0 */
- status = okay;
- };
- pcie@10,0 {
- /* Port 3, Lane 0 */
- status = okay;
- };
- };
};
};
};
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 3e14e82..266696f 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -40,6 +40,7 @@
soc {
ranges = 0x0001 0 0 0xd000 0x10
+ 0x0002 0 0 0xe000 0x810
MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x100;
@@ -71,6 +72,27 @@
};
};
+ pcie-controller {
+ status = okay;
+
+ /*
+* The 3 slots are physically present as
+* standard
Re: [PATCH v3 00/12] MBus device tree binding
On 06/18/13 13:25, Ezequiel Garcia wrote:
In the example below there's an extract of a device tree showing how
the internal-regs and pcie nodes can be represented:
#define MBUS_ID(target,attributes) (((target) 24) | ((attributes)
16))
soc {
compatible = marvell,armadaxp-mbus;
reg = 0 0xd002 0 0x100, 0 0xd0020180 0 0x20;
ranges = 0x0001 0 0 0xd000 0x10 /* internal-regs
*/
0x 0 0 0xe000 0x810 /* pcie */
MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x800;
Ezequiel,
you should update PCIE above (and possibly anywhere else) too.
pcie-controller {
compatible = marvell,armada-xp-pcie;
status = okay;
device_type = pci;
#address-cells = 3;
#size-cells = 2;
ranges =
0x8200 0 0x4 0x0001 0x4 0
0x2000 /* Port 0.0 registers */
0x8200 0 0x42000 0x0001 0x42000 0
0x2000 /* Port 2.0 registers */
0x8200 0 0x44000 0x0001 0x44000 0
0x2000 /* Port 0.1 registers */
0x8200 0 0x48000 0x0001 0x48000 0
0x2000 /* Port 0.2 registers */
0x8200 0 0x4c000 0x0001 0x4c000 0
0x2000 /* Port 0.3 registers */
0x8200 0 0x8 0x0001 0x8 0
0x2000 /* Port 1.0 registers */
0x8200 0 0x82000 0x0001 0x82000 0
0x2000 /* Port 3.0 registers */
0x8200 0 0xe000 0x 0 0
0x0800 /* non-prefetchable memory */
0x8100 0 0 0x 0x800 0
0x0010; /* downstream I/O */
Here for example.
Changes from v2:
* Replaced the PCIe mapping with 0x0002, to avoid using a representation
that might correspond to a possible window id.
Out of curiosity, how will these fake mappings play with LPAE? If you
extend possible address space to 32b the lower bits may belong to valid
addresses.
Maybe you can (already do?) ignore that because of the 32b address
restriction for internal registers IIRC Thomas mentioned?
Sebastian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 02/10] pinctrl: mvebu: dove pinctrl driver
On Thu, Sep 13, 2012 at 05:41:44PM +0200, Sebastian Hesselbarth wrote:
+#define DOVE_GLOBAL_CONFIG_1 (DOVE_SB_REGS_VIRT_BASE | 0xe802C)
+#define DOVE_TWSI_ENABLE_OPTION1BIT(7)
+#define DOVE_GLOBAL_CONFIG_2 (DOVE_SB_REGS_VIRT_BASE | 0xe8030)
+#define DOVE_TWSI_ENABLE_OPTION2BIT(20)
+#define DOVE_TWSI_ENABLE_OPTION3BIT(21)
+#define DOVE_TWSI_OPTION3_GPIO BIT(22)
...
+static int dove_twsi_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
+ unsigned long config)
+{
+ unsigned long gcfg1 = readl(DOVE_GLOBAL_CONFIG_1);
+ unsigned long gcfg2 = readl(DOVE_GLOBAL_CONFIG_2);
+
+ gcfg1 = ~DOVE_TWSI_ENABLE_OPTION1;
+ gcfg2 = ~(DOVE_TWSI_ENABLE_OPTION2 | DOVE_TWSI_ENABLE_OPTION2);
+
+ switch (config) {
+ case 1:
+ gcfg1 |= DOVE_TWSI_ENABLE_OPTION1;
+ break;
+ case 2:
+ gcfg2 |= DOVE_TWSI_ENABLE_OPTION2;
+ break;
+ case 3:
+ gcfg2 |= DOVE_TWSI_ENABLE_OPTION3;
+ break;
+ }
+
+ writel(gcfg1, DOVE_GLOBAL_CONFIG_1);
+ writel(gcfg2, DOVE_GLOBAL_CONFIG_2);
+
+ return 0;
+}
So, I've just been thinking about the LCD clocking on the Armada 510,
and found that there's dividers for the internal LCD clocks in the
global config 1/2 registers. So I grepped the kernel source for
references to these, expecting to find something in drivers/clk, but
found the above.
Now, the reason that I'm replying to this is that we're again falling
into the same trap that we did with SA1100 devices. Back in those
days, there wasn't so much of a problem because the kernel was basically
single threaded when it came to code like the above on such platforms.
There was no kernel preemption.
However, todays kernel is sometimes SMP, commonly with kernel preemption
enabled, maybe even RT. This makes things like the above sequence a
problem where a multifunction register is read, modified and then
written back.
Consider two threads doing this, and a preemption event happening in the
middle of this sequence to another thread also doing a read-modify-write
of the same register. Which one wins depends on the preemption sequence,
but ultimately one loses out.
Any access to such registers needs careful thought, and protection in some
manner.
Maybe what we need is something like this:
static DEFINE_SPINLOCK(io_lock);
static void modifyl(u32 new, u32 mask, void __iomem *reg)
{
unsigned long flags;
u32 val;
spin_lock_irqsave(io_lock, flags);
val = readl(reg) ~mask;
val |= new | mask;
writel(val, reg);
spin_unlock_irqrestore(io_lock, flags);
}
in order to provide arbitrated access to these kinds of multifunction
registers in a safe, platform agnostic way.
Comments?
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control
Hi, On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote: Thanks all, On Fri, Jun 14, 2013 at 11:39 AM, 김승우 sw0312@samsung.com wrote: Hello Kishon, On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote: Hi, On Thursday 13 June 2013 04:51 PM, Inki Dae wrote: -Original Message- From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com] Sent: Thursday, June 13, 2013 5:56 PM To: Rahul Sharma Cc: Rahul Sharma; Inki Dae; linux-samsung-...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; DRI mailing list; Kukjin Kim; Seung-Woo Kim; Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren; grant.lik...@linaro.org Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control Hi, On 06/13/2013 06:26 AM, Rahul Sharma wrote: Mr. Dae, Thanks for your valuable inputs. I posted it as RFC because, I also have received comments to register hdmiphy as a clock controller. As we always configure it for specific frequency, hdmi-phy looks similar to a PLL. But it really doesn't belong to that class. Secondly prior to exynos5420, it was a i2c device. I am not sure we can register a I2C device as a clock controller. I wanted to discuss and explore this option here. Have you considered using the generic PHY framework for those HDMI PHY devices [1] ? I guess we could add a dedicated group of ops for video PHYs, similarly as is is done with struct v4l2_subdev_ops. For configuring things like the carrier/pixel clock frequency or anything what's common across the video PHYs. Perhaps you could have a look and see if this framework would be useful for HDMI and possibly point out anything what might be missing ? I'm not sure it it really solves the issues specific to the Exynos HDMI but at least with a generic PHY driver the PHY module would be separate from the PHY controller, as often same HDMI DPHY can be used with various types of a HDMI controller. So this would allow to not duplicate the HDMI PHY drivers in the long-term perspective. Yeah, at least, it seems that we could use PHY module to control PMU register, HDMI_PHY_CONTROL. However, PHY module provides only init/on/off callbacks. As you may know, HDMIPHY needs i2c interfaces to control HDMIPHY clock. So with PHY module, HDMIPHY driver could enable PMU more generically, but also has to use existing i2c stuff to control HDMIPHY clock. I had a quick review to Generic PHY Framework[v6] but I didn't see that the PHY module could generically support more features such as i2c stuff. I don't think PHY framework needs to provide i2c interfaces to program certain configurations. Instead in one of the callbacks (init/on/off) PHY driver can program whatever it wants using any of the interfaces it needs. IMO PHY framework should work independent of the interfaces. In exnoys hdmi case, i2c interface is not the exact issue. In exynos hdmi, hdmiphy should send i2c configuration about video clock information as the video mode information including resolution, bit per pixel, refresh rate passed from drm subsystem. So init/on/off callbacks of phy framework are not enough for exynos hdmiphy and it should have a callback to set video mode. Do you have plan to add driver specific extend callback pointers to phy framework? Currently, hdmi directly calls phy operations, but Rahul's another patch set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is connected with exynos hdmi own sub driver callback operations. IMHO, if phy framework can support extend callback feature, then this own sub driver callbacks can be replaced with phy framework at long term view. Extended callbacks are always welcome. I can also use phy device private data to pass on private ops like get_pixelclk and set_pixelclk. I would recommend creating a wrapper to the existing PHY framework for HDMI PHY. That way, we can have other HDMI phys added easily. We need to figure out all the ops that might be needed by the HDMI PHY to be added to the wrapper. IMO extended callbacks can lead to abuse of the system and should be used only when absolutely necessary. Thanks Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 06/12] memory: mvebu-devbus: Remove address decoding window workaround
On Tue, Jun 18, 2013 at 08:25:31AM -0300, Ezequiel Garcia wrote:
Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/memory/mvebu-devbus.c | 64
++-
1 file changed, 2 insertions(+), 62 deletions(-)
Unfortunately, the patch adding mvebu-devbus is going through gregkh's
tree. Either this patch needs to wait for v3.12, or ask Greg if he can
take this one.
thx,
Jason.
diff --git a/drivers/memory/mvebu-devbus.c b/drivers/memory/mvebu-devbus.c
index 978e8e3..94c9248 100644
--- a/drivers/memory/mvebu-devbus.c
+++ b/drivers/memory/mvebu-devbus.c
@@ -208,16 +208,11 @@ static int mvebu_devbus_probe(struct platform_device
*pdev)
{
struct device *dev = pdev-dev;
struct device_node *node = pdev-dev.of_node;
- struct device_node *parent;
struct devbus *devbus;
struct resource *res;
struct clk *clk;
unsigned long rate;
- const __be32 *ranges;
- int err, cs;
- int addr_cells, p_addr_cells, size_cells;
- int ranges_len, tuple_len;
- u32 base, size;
+ int err;
devbus = devm_kzalloc(pdev-dev, sizeof(struct devbus), GFP_KERNEL);
if (!devbus)
@@ -248,68 +243,13 @@ static int mvebu_devbus_probe(struct platform_device
*pdev)
return err;
/*
- * Allocate an address window for this device.
- * If the device probing fails, then we won't be able to
- * remove the allocated address decoding window.
- *
- * FIXME: This is only a temporary hack! We need to do this here
- * because we still don't have device tree bindings for mbus.
- * Once that support is added, we will declare these address windows
- * statically in the device tree, and remove the window configuration
- * from here.
- */
-
- /*
- * Get the CS to choose the window string.
- * This is a bit hacky, but it will be removed once the
- * address windows are declared in the device tree.
- */
- cs = (((unsigned long)devbus-base) % 0x400) / 8;
-
- /*
- * Parse 'ranges' property to obtain a (base,size) window tuple.
- * This will be removed once the address windows
- * are declared in the device tree.
- */
- parent = of_get_parent(node);
- if (!parent)
- return -EINVAL;
-
- p_addr_cells = of_n_addr_cells(parent);
- of_node_put(parent);
-
- addr_cells = of_n_addr_cells(node);
- size_cells = of_n_size_cells(node);
- tuple_len = (p_addr_cells + addr_cells + size_cells) * sizeof(__be32);
-
- ranges = of_get_property(node, ranges, ranges_len);
- if (ranges == NULL || ranges_len != tuple_len)
- return -EINVAL;
-
- base = of_translate_address(node, ranges + addr_cells);
- if (base == OF_BAD_ADDR)
- return -EINVAL;
- size = of_read_number(ranges + addr_cells + p_addr_cells, size_cells);
-
- /*
- * Create an mbus address windows.
- * FIXME: Remove this, together with the above code, once the
- * address windows are declared in the device tree.
- */
- err = mvebu_mbus_add_window(devbus_wins[cs], base, size);
- if (err 0)
- return err;
-
- /*
* We need to create a child device explicitly from here to
* guarantee that the child will be probed after the timing
* parameters for the bus are written.
*/
err = of_platform_populate(node, NULL, NULL, dev);
- if (err 0) {
- mvebu_mbus_del_window(base, size);
+ if (err 0)
return err;
- }
return 0;
}
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 02/10] pinctrl: mvebu: dove pinctrl driver
On 06/18/13 13:36, Russell King - ARM Linux wrote:
On Thu, Sep 13, 2012 at 05:41:44PM +0200, Sebastian Hesselbarth wrote:
+#define DOVE_GLOBAL_CONFIG_1 (DOVE_SB_REGS_VIRT_BASE | 0xe802C)
+#define DOVE_TWSI_ENABLE_OPTION1 BIT(7)
+#define DOVE_GLOBAL_CONFIG_2 (DOVE_SB_REGS_VIRT_BASE | 0xe8030)
+#define DOVE_TWSI_ENABLE_OPTION2 BIT(20)
+#define DOVE_TWSI_ENABLE_OPTION3 BIT(21)
+#define DOVE_TWSI_OPTION3_GPIOBIT(22)
...
Russell,
the above absolute addresses already made me think of cleaning up dove
pinctrl a while ago. I also had in mind that below function exclusively
request ownership of global config registers.
+static int dove_twsi_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
+ unsigned long config)
+{
+ unsigned long gcfg1 = readl(DOVE_GLOBAL_CONFIG_1);
+ unsigned long gcfg2 = readl(DOVE_GLOBAL_CONFIG_2);
+
+ gcfg1 = ~DOVE_TWSI_ENABLE_OPTION1;
+ gcfg2 = ~(DOVE_TWSI_ENABLE_OPTION2 | DOVE_TWSI_ENABLE_OPTION2);
+
+ switch (config) {
+ case 1:
+ gcfg1 |= DOVE_TWSI_ENABLE_OPTION1;
+ break;
+ case 2:
+ gcfg2 |= DOVE_TWSI_ENABLE_OPTION2;
+ break;
+ case 3:
+ gcfg2 |= DOVE_TWSI_ENABLE_OPTION3;
+ break;
+ }
+
+ writel(gcfg1, DOVE_GLOBAL_CONFIG_1);
+ writel(gcfg2, DOVE_GLOBAL_CONFIG_2);
+
+ return 0;
+}
So, I've just been thinking about the LCD clocking on the Armada 510,
and found that there's dividers for the internal LCD clocks in the
global config 1/2 registers. So I grepped the kernel source for
references to these, expecting to find something in drivers/clk, but
found the above.
We have no peripheral clock handling for Dove, yet. Just core clocks and
clock gates are implemented. And I guess they are DT only anyway.
However, todays kernel is sometimes SMP, commonly with kernel preemption
enabled, maybe even RT. This makes things like the above sequence a
problem where a multifunction register is read, modified and then
written back.
Consider two threads doing this, and a preemption event happening in the
middle of this sequence to another thread also doing a read-modify-write
of the same register. Which one wins depends on the preemption sequence,
but ultimately one loses out.
Yeah, sure. We have the same issue with watchdog driver messing with
timer registers. There I exported a function to _clrset TIMER_CTRL
register safely. Just went into irqchip (tip for-next).
Any access to such registers needs careful thought, and protection in some
manner.
Maybe what we need is something like this:
static DEFINE_SPINLOCK(io_lock);
static void modifyl(u32 new, u32 mask, void __iomem *reg)
{
unsigned long flags;
u32 val;
spin_lock_irqsave(io_lock, flags);
val = readl(reg) ~mask;
val |= new | mask;
writel(val, reg);
spin_unlock_irqrestore(io_lock, flags);
}
in order to provide arbitrated access to these kinds of multifunction
registers in a safe, platform agnostic way.
I am fine with a generic modify function with a single lock. Most cases
should be fine with a single lock even for non-related register
accesses, e.g. watchdog will access TIMER_CTRL only once to enable
itself. If you think you need a special lock because you have a lot of
writes to shared registers, you can still have your own modify lock.
Sebastian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] [media] coda: fix missing unlock on error in coda_stop_streaming()
On 06/18/2013 06:03 PM, Philipp Zabel wrote:
Am Dienstag, den 18.06.2013, 13:00 +0800 schrieb Wei Yongjun:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing unlock before return from function coda_stop_streaming()
in the error handling case.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/media/platform/coda.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index df4ada88..2c3cd17 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -1347,6 +1347,7 @@ static int coda_stop_streaming(struct vb2_queue *q)
if (coda_command_sync(ctx, CODA_COMMAND_SEQ_END)) {
v4l2_err(dev-v4l2_dev,
CODA_COMMAND_SEQ_END failed\n);
+mutex_unlock(dev-coda_mutex);
return -ETIMEDOUT;
}
mutex_unlock(dev-coda_mutex);
Thanks! If you don't mind, I'll integrate this change into the [media]
coda: add CODA7541 decoding support for v2.
No problem. Thanks.
Yongjun Wei
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/4] drm/exynos: fix interlace resolutions for exynos5420
Modified code for calculating hdmi IP register values from drm timing
values. The modification is based on the inputs from hw team and specifically
proposed for 1440x576i and 1440x480i. But same changes holds good for other
interlaced resolutions also.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 8752171..2f807d5 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1557,8 +1557,7 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
(m-vsync_start - m-vdisplay) / 2);
hdmi_set_reg(core-v2_blank, 2, m-vtotal / 2);
hdmi_set_reg(core-v1_blank, 2, (m-vtotal - m-vdisplay) / 2);
- hdmi_set_reg(core-v_blank_f0, 2, (m-vtotal +
- ((m-vsync_end - m-vsync_start) * 4) + 5) / 2);
+ hdmi_set_reg(core-v_blank_f0, 2, m-vtotal - m-vdisplay / 2);
hdmi_set_reg(core-v_blank_f1, 2, m-vtotal);
hdmi_set_reg(core-v_sync_line_aft_2, 2, (m-vtotal / 2) + 7);
hdmi_set_reg(core-v_sync_line_aft_1, 2, (m-vtotal / 2) + 2);
@@ -1568,7 +1567,10 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
(m-htotal / 2) + (m-hsync_start - m-hdisplay));
hdmi_set_reg(tg-vact_st, 2, (m-vtotal - m-vdisplay) / 2);
hdmi_set_reg(tg-vact_sz, 2, m-vdisplay / 2);
- hdmi_set_reg(tg-vact_st2, 2, 0x249);/* Reset value + 1*/
+ hdmi_set_reg(tg-vact_st2, 2, m-vtotal - m-vdisplay / 2);
+ hdmi_set_reg(tg-vsync2, 2, (m-vtotal / 2) + 1);
+ hdmi_set_reg(tg-vsync_bot_hdmi, 2, (m-vtotal / 2) + 1);
+ hdmi_set_reg(tg-field_bot_hdmi, 2, (m-vtotal / 2) + 1);
hdmi_set_reg(tg-vact_st3, 2, 0x0);
hdmi_set_reg(tg-vact_st4, 2, 0x0);
} else {
@@ -1590,6 +1592,9 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
hdmi_set_reg(tg-vact_st2, 2, 0x248); /* Reset value */
hdmi_set_reg(tg-vact_st3, 2, 0x47b); /* Reset value */
hdmi_set_reg(tg-vact_st4, 2, 0x6ae); /* Reset value */
+ hdmi_set_reg(tg-vsync2, 2, 0x233); /* Reset value */
+ hdmi_set_reg(tg-vsync_bot_hdmi, 2, 0x233); /* Reset value */
+ hdmi_set_reg(tg-field_bot_hdmi, 2, 0x233); /* Reset value */
}
/* Following values calculations are same irrespective of mode type */
@@ -1621,12 +1626,9 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
hdmi_set_reg(tg-hact_sz, 2, m-hdisplay);
hdmi_set_reg(tg-v_fsz, 2, m-vtotal);
hdmi_set_reg(tg-vsync, 2, 0x1);
- hdmi_set_reg(tg-vsync2, 2, 0x233); /* Reset value */
hdmi_set_reg(tg-field_chg, 2, 0x233); /* Reset value */
hdmi_set_reg(tg-vsync_top_hdmi, 2, 0x1); /* Reset value */
- hdmi_set_reg(tg-vsync_bot_hdmi, 2, 0x233); /* Reset value */
hdmi_set_reg(tg-field_top_hdmi, 2, 0x1); /* Reset value */
- hdmi_set_reg(tg-field_bot_hdmi, 2, 0x233); /* Reset value */
hdmi_set_reg(tg-tg_3d, 1, 0x0);
}
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] ARM: OMAP2+: dts: HACK: Provide alias to USB PHY clock
On 06/18/2013 02:23 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130618 04:17]: Till the OMAP clocks are correctly defined in device tree, use this temporary hack to provide clock alias to the USB PHY clocks. Without this, USB Host Ethernet will not be functional with device tree boots on Panda and uEVM. Thanks, this looks OK to me to have USB working until we have the DT defined clock patches ready. The $Subject needs updating though, just make it ARM: OMAP2+: and leave out the dts and hack from there. OK. will send v2 as i need to make another minor change in the panda dts file. cheers, -roger ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 06/12] memory: mvebu-devbus: Remove address decoding window workaround
On Tue, Jun 18, 2013 at 02:17:31PM +0200, Thomas Petazzoni wrote: Dear Jason Cooper, On Tue, 18 Jun 2013 07:39:20 -0400, Jason Cooper wrote: On Tue, Jun 18, 2013 at 08:25:31AM -0300, Ezequiel Garcia wrote: Now that mbus device tree binding has been introduced, remove the address decoding window management from this driver. A suitable 'ranges' entry should be added to the devbus-compatible node in the device tree, as described by the mbus binding documentation. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- drivers/memory/mvebu-devbus.c | 64 ++- 1 file changed, 2 insertions(+), 62 deletions(-) Unfortunately, the patch adding mvebu-devbus is going through gregkh's tree. Either this patch needs to wait for v3.12, or ask Greg if he can take this one. I believe that what we're looking for right now is a Acked-by from both the Marvell maintainers, Arnd Bergmann and Jason Gunthorpe. Once we get those Acked-by, we can figure out the merge strategy for this patch set. Right. I was more looking to give Ezequiel a heads up because I think he will have to extract devbus related changes out of the patches later in this series. I haven't had time to look closely yet, but wanted to toss it out there so it didn't rear it's head later and throw things off track. thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 5/9] ARM: OMAP: USB: Add phy binding information
Hi, On Tue, Jun 18, 2013 at 04:43:44PM +0530, Kishon Vijay Abraham I wrote: On Tue, Jun 18, 2013 at 03:34:36PM +0530, Kishon Vijay Abraham I wrote: On Tuesday 18 June 2013 03:14 PM, Felipe Balbi wrote: On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote: In order for controllers to get PHY in case of non dt boot, the phy binding information (phy device name) should be added in the platform data of the controller. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com I would rather not pass strings around, any other way to handle this ? Why do you need to pass this string ? Our old way of binding the controller and the phy using device name started creating problems after the devices are created using PLATFORM_DEVID_AUTO. Infact non-dt boot is broken in mainline for OMAP3 platforms for which I have posted a RFC series http://www.serverphorums.com/read.php?12,708632 which also uses strings. I'm not sure of any other way to deal with this. have you checked how other frameworks handle it ? Regulator has some sort of binding in board-files, but I guess it passes the regulator name? From whatever I could make of, regulator has 3 ways to get the regulator one of which is using the binding in board-files (but it also uses device name which could create the same problem that we are facing). 1.) from dt data 2.) from _supply_ name 3.) from binding in board file (referred regulator_dev_lookup() in regulator/core.c) right, spot on. Which means we don't have a better, more elegant solution now. Let's go ahead with this. -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 06/12] memory: mvebu-devbus: Remove address decoding window workaround
On Tue, Jun 18, 2013 at 08:33:54AM -0400, Jason Cooper wrote: On Tue, Jun 18, 2013 at 02:17:31PM +0200, Thomas Petazzoni wrote: Dear Jason Cooper, On Tue, 18 Jun 2013 07:39:20 -0400, Jason Cooper wrote: On Tue, Jun 18, 2013 at 08:25:31AM -0300, Ezequiel Garcia wrote: Now that mbus device tree binding has been introduced, remove the address decoding window management from this driver. A suitable 'ranges' entry should be added to the devbus-compatible node in the device tree, as described by the mbus binding documentation. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- drivers/memory/mvebu-devbus.c | 64 ++- 1 file changed, 2 insertions(+), 62 deletions(-) Unfortunately, the patch adding mvebu-devbus is going through gregkh's tree. Either this patch needs to wait for v3.12, or ask Greg if he can take this one. I believe that what we're looking for right now is a Acked-by from both the Marvell maintainers, Arnd Bergmann and Jason Gunthorpe. Once we get those Acked-by, we can figure out the merge strategy for this patch set. Right. I was more looking to give Ezequiel a heads up .. and you did :) 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: [PATCH v3 00/12] MBus device tree binding
Hi Sebastian,
On Tue, Jun 18, 2013 at 01:33:37PM +0200, Sebastian Hesselbarth wrote:
On 06/18/13 13:25, Ezequiel Garcia wrote:
In the example below there's an extract of a device tree showing how
the internal-regs and pcie nodes can be represented:
#define MBUS_ID(target,attributes) (((target) 24) | ((attributes)
16))
soc {
compatible = marvell,armadaxp-mbus;
reg = 0 0xd002 0 0x100, 0 0xd0020180 0 0x20;
ranges = 0x0001 0 0 0xd000 0x10 /* internal-regs
*/
0x 0 0 0xe000 0x810 /* pcie */
MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x800;
Ezequiel,
you should update PCIE above (and possibly anywhere else) too.
Right. I've just checked and I only forgot to update the PCIe first-cell
(0x - 0x0002) in this cover-letter. The device tree files
and the documentation look correct.
Sorry for the confusion!
pcie-controller {
compatible = marvell,armada-xp-pcie;
status = okay;
device_type = pci;
#address-cells = 3;
#size-cells = 2;
ranges =
0x8200 0 0x4 0x0001 0x4 0
0x2000 /* Port 0.0 registers */
0x8200 0 0x42000 0x0001 0x42000 0
0x2000 /* Port 2.0 registers */
0x8200 0 0x44000 0x0001 0x44000 0
0x2000 /* Port 0.1 registers */
0x8200 0 0x48000 0x0001 0x48000 0
0x2000 /* Port 0.2 registers */
0x8200 0 0x4c000 0x0001 0x4c000 0
0x2000 /* Port 0.3 registers */
0x8200 0 0x8 0x0001 0x8 0
0x2000 /* Port 1.0 registers */
0x8200 0 0x82000 0x0001 0x82000 0
0x2000 /* Port 3.0 registers */
0x8200 0 0xe000 0x 0 0
0x0800 /* non-prefetchable memory */
0x8100 0 0 0x 0x800 0
0x0010; /* downstream I/O */
Here for example.
Changes from v2:
* Replaced the PCIe mapping with 0x0002, to avoid using a
representation
that might correspond to a possible window id.
Out of curiosity, how will these fake mappings play with LPAE? If you
extend possible address space to 32b the lower bits may belong to valid
addresses.
Maybe you can (already do?) ignore that because of the 32b address
restriction for internal registers IIRC Thomas mentioned?
That's a tricky question. The best explanation I can give you is that
these fake mappings belong to the MBus children address space, which is
different from the physical address space where LPAE comes into play.
This MBus children address space consists of two 32-bit cells:
IIAA00CC 00oo
The first one encodes the target ID and attribute in its upper 16 bits,
and custom values for the fake mappings in the lower 8 bits.
The second one encodes the offset into the MBus decoding window, and
this window can be as large as 4 GiB.
The address space I've just described is not the physical 64-bit address
space; it's the one where MBus children sit.
I hope I understood you're question, and I hope any of the above makes
sense!
--
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: [PATCH v11 0/8] ] DMA Engine support for AM33XX
On Tuesday 18 June 2013, Joel A Fernandes wrote: This series is a repost of Matt Porter's EDMA patches for AM33XX EDMA support with changes for few pending review comments on v9 series. Currently this is required for AM33XX (Beaglebone or EVM) to access MMC and be able mount to rootfs and boot till command prompt over MMC. Unless there are other pending review comments, I hope this series can make it into 3.11 merge window, the dependent series has been posted at [1] and completed review. Tested EDMA on AM1808 EVM and AM33XX Beaglebone with MMC. Acked-by: Arnd Bergmann a...@arndb.de The binding looks good now. My usual comment about the fact that we shouldn't use a filter function in .xlate() applies here, but that is more about the missing interface of the dmaengine layer than the particular driver. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: dts: Change dw-apb-timer-osc and dw-apb-timer-sp to just dw-apb-timer
On Tuesday 18 June 2013, dingu...@altera.com wrote:
@@ -476,27 +476,31 @@
};
timer0: timer0@ffc08000 {
- compatible = snps,dw-apb-timer-sp;
+ compatible = snps,dw-apb-timer;
interrupts = 0 167 4;
reg = 0xffc08000 0x1000;
+ clocks = osc;
};
timer1: timer1@ffc09000 {
- compatible = snps,dw-apb-timer-sp;
+ compatible = snps,dw-apb-timer;
interrupts = 0 168 4;
reg = 0xffc09000 0x1000;
+ clocks = osc;
};
I think it would make sense to fix the device name as well, they should
all be named timer, not timer0, so I would add
- timer0: timer0@ffc08000 {
+ timer0: timer@ffc08000 {
for all the timers in the dts file here.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/5] mfd: twl4030-power: Split from twl-core into a dedicated module
For now, the call to twl4030-power is hard-wired inside twl-core.
To ease the future transition to DT, make twl4030-power as a
separate module, like what is already done for twl4030-audio
and others.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
drivers/mfd/twl-core.c | 12 +++---
drivers/mfd/twl4030-power.c | 44 +-
include/linux/i2c/twl.h |1 -
3 files changed, 42 insertions(+), 15 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 8d9bc10..dbd52b3 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -1023,6 +1023,14 @@ add_children(struct twl4030_platform_data *pdata,
unsigned irq_base,
return PTR_ERR(child);
}
+ if (IS_ENABLED(CONFIG_TWL4030_POWER) pdata-power) {
+ child = add_child(TWL_MODULE_PM_MASTER, twl4030_power,
+ pdata-power, sizeof(*pdata-power), false,
+ 0, 0);
+ if (IS_ERR(child))
+ return PTR_ERR(child);
+ }
+
return 0;
}
@@ -1234,10 +1242,6 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
WARN(status 0, Error: reading twl_idcode register value\n);
}
- /* load power event scripts */
- if (IS_ENABLED(CONFIG_TWL4030_POWER) pdata pdata-power)
- twl4030_power_init(pdata-power);
-
/* Maybe init the T2 Interrupt subsystem */
if (client-irq) {
if (twl_class_is_4030()) {
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index dd362c1..7ade81b 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -507,8 +507,9 @@ void twl4030_power_off(void)
pr_err(TWL4030 Unable to power off\n);
}
-void twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
+int twl4030_power_probe(struct platform_device *pdev)
{
+ struct twl4030_power_data *pdata = pdev-dev.platform_data;
int err = 0;
int i;
struct twl4030_resconfig *resconfig;
@@ -524,14 +525,14 @@ void twl4030_power_init(struct twl4030_power_data
*twl4030_scripts)
if (err)
goto unlock;
- for (i = 0; i twl4030_scripts-num; i++) {
- err = load_twl4030_script(twl4030_scripts-scripts[i], address);
+ for (i = 0; i pdata-num; i++) {
+ err = load_twl4030_script(pdata-scripts[i], address);
if (err)
goto load;
- address += twl4030_scripts-scripts[i]-size;
+ address += pdata-scripts[i]-size;
}
- resconfig = twl4030_scripts-resource_config;
+ resconfig = pdata-resource_config;
if (resconfig) {
while (resconfig-resource) {
err = twl4030_configure_resource(resconfig);
@@ -543,7 +544,7 @@ void twl4030_power_init(struct twl4030_power_data
*twl4030_scripts)
}
/* Board has to be wired properly to use this feature */
- if (twl4030_scripts-use_poweroff !pm_power_off) {
+ if (pdata-use_poweroff !pm_power_off) {
/* Default for SEQ_OFFSYNC is set, lets ensure this */
err = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, val,
TWL4030_PM_MASTER_CFG_P123_TRANSITION);
@@ -568,18 +569,41 @@ relock:
TWL4030_PM_MASTER_PROTECT_KEY);
if (err)
pr_err(TWL4030 Unable to relock registers\n);
- return;
+ return err;
unlock:
if (err)
pr_err(TWL4030 Unable to unlock registers\n);
- return;
+ return err;
load:
if (err)
pr_err(TWL4030 failed to load scripts\n);
- return;
+ return err;
resource:
if (err)
pr_err(TWL4030 failed to configure resource\n);
- return;
+ return err;
}
+
+static int twl4030_power_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct platform_driver twl4030_power_driver = {
+ .driver = {
+ .name = twl4030_power,
+ .owner = THIS_MODULE,
+ },
+ .probe = twl4030_power_probe,
+ .remove = twl4030_power_remove,
+};
+
+module_platform_driver(twl4030_power_driver);
+
+MODULE_AUTHOR(Nokia Corporation);
+MODULE_AUTHOR(Texas Instruments, Inc.);
+MODULE_DESCRIPTION(Power management for TWL4030);
+MODULE_LICENSE(GPL);
+MODULE_ALIAS(platform:twl4030_power);
+
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 488debb..2167c0d0 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -658,7 +658,6 @@ struct twl4030_power_data {
bool use_poweroff; /* Board is wired for TWL poweroff */
};
-extern void twl4030_power_init(struct twl4030_power_data *triton2_scripts);
extern int
[PATCH v2 0/5] mfd: twl4030-power: Start DT conversion and updates
Hello, This series enables a partial DT support for twl4030-power. The missing part is the power management scripts, as the required binding should be defined first. It however enables the complete shutdown of the processor at poweroff when booting with DT, dropping the power consumption from around 350 mA on Overo+Tobi to about 40 mA. The poweroff callback was tested with both DT and non-DT boots. The last two patches simplify the error path in the probe function, and fix registers relocking on error. Best regards, Florian Since v1: - use module_platform_driver() - split the refactoring of the probe function into a dedicated patch - new patch to fix registers relocking on error - rebased on mfd-next Florian Vaussard (5): mfd: twl4030-power: Split from twl-core into a dedicated module mfd: twl4030-power: Simplify probing of power scripts and resources mfd: twl4030-power: Start transition to DT mfd: twl4030-power: Simplify error path mfd: twl4030-power: Fix relocking on error .../devicetree/bindings/mfd/twl4030-power.txt | 28 drivers/mfd/twl-core.c | 12 +- drivers/mfd/twl4030-power.c| 149 ++- include/linux/i2c/twl.h|1 - 4 files changed, 146 insertions(+), 44 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/twl4030-power.txt -- 1.7.5.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/5] mfd: twl4030-power: Simplify probing of power scripts and resources
Increase lisibility when probing power scripts and resources by
creating dedicated functions.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
drivers/mfd/twl4030-power.c | 60 --
1 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 7ade81b..8fa6c7b 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -492,6 +492,39 @@ int twl4030_remove_script(u8 flags)
return err;
}
+int twl4030_power_configure_scripts(struct twl4030_power_data *pdata)
+{
+ int err;
+ int i;
+ u8 address = twl4030_start_script_address;
+
+ for (i = 0; i pdata-num; i++) {
+ err = load_twl4030_script(pdata-scripts[i], address);
+ if (err)
+ return err;
+ address += pdata-scripts[i]-size;
+ }
+
+ return 0;
+}
+
+int twl4030_power_configure_resources(struct twl4030_power_data *pdata)
+{
+ struct twl4030_resconfig *resconfig = pdata-resource_config;
+ int err;
+
+ if (resconfig) {
+ while (resconfig-resource) {
+ err = twl4030_configure_resource(resconfig);
+ if (err)
+ return err;
+ resconfig++;
+ }
+ }
+
+ return 0;
+}
+
/*
* In master mode, start the power off sequence.
* After a successful execution, TWL shuts down the power to the SoC
@@ -511,9 +544,7 @@ int twl4030_power_probe(struct platform_device *pdev)
{
struct twl4030_power_data *pdata = pdev-dev.platform_data;
int err = 0;
- int i;
- struct twl4030_resconfig *resconfig;
- u8 val, address = twl4030_start_script_address;
+ u8 val;
err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, TWL4030_PM_MASTER_KEY_CFG1,
TWL4030_PM_MASTER_PROTECT_KEY);
@@ -525,23 +556,12 @@ int twl4030_power_probe(struct platform_device *pdev)
if (err)
goto unlock;
- for (i = 0; i pdata-num; i++) {
- err = load_twl4030_script(pdata-scripts[i], address);
- if (err)
- goto load;
- address += pdata-scripts[i]-size;
- }
-
- resconfig = pdata-resource_config;
- if (resconfig) {
- while (resconfig-resource) {
- err = twl4030_configure_resource(resconfig);
- if (err)
- goto resource;
- resconfig++;
-
- }
- }
+ err = twl4030_power_configure_scripts(pdata);
+ if (err)
+ goto load;
+ err = twl4030_power_configure_resources(pdata);
+ if (err)
+ goto resource;
/* Board has to be wired properly to use this feature */
if (pdata-use_poweroff !pm_power_off) {
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 5/5] mfd: twl4030-power: Fix relocking on error
If an error occurs when loading power scripts or resources, the
registers are not correctly relocked. Fix it.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
drivers/mfd/twl4030-power.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 1c19d82..a8b33c9 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -558,6 +558,7 @@ int twl4030_power_probe(struct platform_device *pdev)
struct twl4030_power_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
int err = 0;
+ int err2 = 0;
u8 val;
if (!pdata !node) {
@@ -581,12 +582,12 @@ int twl4030_power_probe(struct platform_device *pdev)
err = twl4030_power_configure_scripts(pdata);
if (err) {
pr_err(TWL4030 failed to load scripts\n);
- return err;
+ goto relock;
}
err = twl4030_power_configure_resources(pdata);
if (err) {
pr_err(TWL4030 failed to configure resource\n);
- return err;
+ goto relock;
}
}
@@ -612,10 +613,13 @@ int twl4030_power_probe(struct platform_device *pdev)
}
relock:
- err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, 0,
+ err2 = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, 0,
TWL4030_PM_MASTER_PROTECT_KEY);
- if (err)
+ if (err2) {
pr_err(TWL4030 Unable to relock registers\n);
+ return err2;
+ }
+
return err;
}
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 3/5] mfd: twl4030-power: Start transition to DT
Support for loading twl4030-power module via devicetree.
For now, when booting with a DT, only the poweroff callback
feature is supported through the ti,use_poweroff property.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
.../devicetree/bindings/mfd/twl4030-power.txt | 28
drivers/mfd/twl4030-power.c| 45 ---
2 files changed, 66 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/twl4030-power.txt
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
new file mode 100644
index 000..8e15ec3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -0,0 +1,28 @@
+Texas Instruments TWL family (twl4030) reset and power management module
+
+The power management module inside the TWL family provides several facilities
+to control the power resources, including power scripts. For now, the
+binding only supports the complete shutdown of the system after poweroff.
+
+Required properties:
+- compatible : must be ti,twl4030-power
+
+Optional properties:
+- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
+ SLEEP-to-OFF transition when the system poweroffs.
+
+Example:
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+
+ twl_power: power {
+ compatible = ti,twl4030-power;
+ ti,use_poweroff;
+ };
+ };
+};
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 8fa6c7b..9f59c94 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -28,6 +28,7 @@
#include linux/pm.h
#include linux/i2c/twl.h
#include linux/platform_device.h
+#include linux/of.h
#include asm/mach-types.h
@@ -540,12 +541,30 @@ void twl4030_power_off(void)
pr_err(TWL4030 Unable to power off\n);
}
+static bool twl4030_power_use_poweroff(struct twl4030_power_data *pdata,
+ struct device_node *node)
+{
+ if (pdata pdata-use_poweroff)
+ return true;
+
+ if (of_property_read_bool(node, ti,use_poweroff))
+ return true;
+
+ return false;
+}
+
int twl4030_power_probe(struct platform_device *pdev)
{
struct twl4030_power_data *pdata = pdev-dev.platform_data;
+ struct device_node *node = pdev-dev.of_node;
int err = 0;
u8 val;
+ if (!pdata !node) {
+ dev_err(pdev-dev, Platform data is missing\n);
+ return -EINVAL;
+ }
+
err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, TWL4030_PM_MASTER_KEY_CFG1,
TWL4030_PM_MASTER_PROTECT_KEY);
if (err)
@@ -556,15 +575,18 @@ int twl4030_power_probe(struct platform_device *pdev)
if (err)
goto unlock;
- err = twl4030_power_configure_scripts(pdata);
- if (err)
- goto load;
- err = twl4030_power_configure_resources(pdata);
- if (err)
- goto resource;
+ if (pdata) {
+ /* TODO: convert to device tree */
+ err = twl4030_power_configure_scripts(pdata);
+ if (err)
+ goto load;
+ err = twl4030_power_configure_resources(pdata);
+ if (err)
+ goto resource;
+ }
/* Board has to be wired properly to use this feature */
- if (pdata-use_poweroff !pm_power_off) {
+ if (twl4030_power_use_poweroff(pdata, node) !pm_power_off) {
/* Default for SEQ_OFFSYNC is set, lets ensure this */
err = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, val,
TWL4030_PM_MASTER_CFG_P123_TRANSITION);
@@ -610,10 +632,19 @@ static int twl4030_power_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl4030_power_of_match[] = {
+ {.compatible = ti,twl4030-power, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, twl4030_power_of_match);
+#endif
+
static struct platform_driver twl4030_power_driver = {
.driver = {
.name = twl4030_power,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(twl4030_power_of_match),
},
.probe = twl4030_power_probe,
.remove = twl4030_power_remove,
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 4/5] mfd: twl4030-power: Simplify error path
Remove unnecessary goto statements, causing duplicated if
conditions.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
drivers/mfd/twl4030-power.c | 38 +++---
1 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 9f59c94..1c19d82 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -567,22 +567,27 @@ int twl4030_power_probe(struct platform_device *pdev)
err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, TWL4030_PM_MASTER_KEY_CFG1,
TWL4030_PM_MASTER_PROTECT_KEY);
- if (err)
- goto unlock;
-
- err = twl_i2c_write_u8(TWL_MODULE_PM_MASTER, TWL4030_PM_MASTER_KEY_CFG2,
+ err |= twl_i2c_write_u8(TWL_MODULE_PM_MASTER,
+ TWL4030_PM_MASTER_KEY_CFG2,
TWL4030_PM_MASTER_PROTECT_KEY);
- if (err)
- goto unlock;
+
+ if (err) {
+ pr_err(TWL4030 Unable to unlock registers\n);
+ return err;
+ }
if (pdata) {
/* TODO: convert to device tree */
err = twl4030_power_configure_scripts(pdata);
- if (err)
- goto load;
+ if (err) {
+ pr_err(TWL4030 failed to load scripts\n);
+ return err;
+ }
err = twl4030_power_configure_resources(pdata);
- if (err)
- goto resource;
+ if (err) {
+ pr_err(TWL4030 failed to configure resource\n);
+ return err;
+ }
}
/* Board has to be wired properly to use this feature */
@@ -612,19 +617,6 @@ relock:
if (err)
pr_err(TWL4030 Unable to relock registers\n);
return err;
-
-unlock:
- if (err)
- pr_err(TWL4030 Unable to unlock registers\n);
- return err;
-load:
- if (err)
- pr_err(TWL4030 failed to load scripts\n);
- return err;
-resource:
- if (err)
- pr_err(TWL4030 failed to configure resource\n);
- return err;
}
static int twl4030_power_remove(struct platform_device *pdev)
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3] dmaengine: add support for DMA multiplexer DT nodes
On Tuesday 18 June 2013, Guennadi Liakhovetski wrote:
Hmm, you've clearly shown that this can work, but it feels like a really
odd way to
do this. I don't think we should do it this way, because it tries to be
really
generic but then cannot some of the interesting cases, e.g.
1. you have multiplexed dma engines, but they need different #dma-cells.
1. you have multiplexed dma engines, but they need different dma specifiers.
2. The mux is between devices that are not on the same parent bus.
Yes, I know about these restrictions. I'm not sure whether we really ever
will get DMA multiplexers with different #dma-cells or DMA specifiers, but
in any case we can make this less generic - either keep it as a generic
uniform multiplexer or making it shdma specific - I'm fine either way.
Ok, let's make it shdma specific then.
I think this should either not try to be fully generic and just limited to
the case you care about, i.e. shdma, or it should be more abstract and
multiplex between the individual channels. In either case, I guess
it would not need a change like this to the of_dma_request_slave_channel()
function, and the node pointer used by the slave would be the same node
that defines the address space for the channel descriptions with #dma-cells.
I think the easiest way would be the first of those two, so it would
essentially look like
dmac: dma-mux {
compatible = renesas,shdma-mux; /* not simple-bus! */
#dma-cells = 1;
#address-cells = 1;
#size-cells = 1;
dma@1000 {
compatible = renesas,shdma;
reg = 0x1000 0x1000;
interrupts = 10;
};
dma@2000 {
compatible = renesas,shdma;
reg = 0x1000 0x1000;
interrupts = 10;
};
}
You then register a device driver for the master device, which
will call of_dma_controller_register() for itself and create
its child devices.
Hmm, it is an interesting idea to only register one struct of_dma instance
for all compatible shdma instances instead of one per shdma controller,
and then call of_platform_populate() to instantiate all shdma instances. A
couple of drawbacks:
1. we'll always have to put a mux DT node in .dts, even if there's just
one DMAC instance on the system.
2. as AUXDATA for the new wrapper device we'll have to use an AUXDATA
array for all child nodes, to be passed to of_platform_populate().
My suggestion above is just one of the possible ways to do it, and I'm
less concerned about it if you make it specific to shdma. Other
options would be:
1 using phandles from the mux to the individual dma engine instances,
but have them as independent nodes.
2 same as 1, but using phandles from the individual instances to the mux
3 Keep using the simple-bus.
4 Have just one combined device node for all shdma instances, with multiple
'reg' and 'interrupts' properties, and handle the muxing in the shdma
driver. You could create platform_device_create_resndata from the
top-level driver to reuse most of the existing code.
In any of these cases you should be able to support both muxed and non-muxed
operation in the shdma driver if you want to. You'd just have two separate
ofdma registrations.
3. it seems confusing to me - having one ofdma instance for multiple
dmaengine devices.
I don't see a better way around this one, but I also don't see it as
problematic.
Wiht a mux, you always end up having just one node that the slaves
point to, but multiple dma_device structures in the kernel. struct ofdma
really refers to the first one.
The advantage is, of course, that we don't need to extend existing OF and
dmaengine APIs.
So, I think, it can be done this way, but do you really think it'd be an
improvement over my original proposal?
My main interest is to keep the shdma specifics out of the generic dmaengine
binding document, where it just complicates the common case.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/4] ARM: dts: omap4-panda: Fix DVI EDID reads
On 06/18/2013 02:11 PM, Roger Quadros wrote: On Panda the +5V supply for DVI EDID is supplied by the same regulator that poweres the USB Hub. Currently, the DSS/DVI subsystem doesn't know how to manage this regulator and so DVI EDID reads will fail if USB Hub is not enabled. As a temporary fix we keep this regulator permanently enabled on boot. This fixes the DVI EDID read problem. CC: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/omap4-panda-common.dtsi |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 7a21e8e..40df79e 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -80,6 +80,11 @@ gpio = gpio1 1 0;/* gpio_1 */ startup-delay-us = 7; enable-active-high; + /* + * FIXME: Remove boot-on when DSS can handle this regulator + * for DVI EDID. + */ + regulator-boot-on; As pointed out by Tomi, the correct usage here is regulator-always-on. The reason I use regulator-boot-on is because the regulator framework doesn't turn on the regulator. (maybe a bug in the regulator framework?) regulator-boot-on is not sufficient as it doesn't prevent drivers from turning it off. e.g. loading and unloading the USB host driver will turn of the regulator. So it must be used along with regulator-always-on I'll fix this in v2. cheers, -roger ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 3/3] DMA: shdma: add DT support
On Tuesday 18 June 2013, Guennadi Liakhovetski wrote:
Hi Arnd
On Mon, 17 Jun 2013, Arnd Bergmann wrote:
On Thursday 06 June 2013, Guennadi Liakhovetski wrote:
+Required properties:
+- dmas: a list of [DMA controller phandle] [MID/RID value]
pairs
+- dma-names: a list of DMA channel names, one per dmas entry
Looks ok to me, although it might be helpful to clarify what MID/RID means,
by expanding the acronym and describing whether one needs to pass both
or just one of them. If both, what is the bit pattern?
One word: magic. MID/RID is what that value is called in the datasheet.
E.g. on APE6 (r8a73a4) it is indeed divided into 2 fields - 2 and 6 bits
for RID and MID respectively, I _guess_ 2 bits are to select a channel
within a slave device and 6 bits to pick up one of slaves, but that
doesn't fit with a slave with 8 channels (HSI), there are also slave
devices with different MID values, so, those values are really better
considered as a single magic value - an 8-bit channel request handle,
which is also how they are listed in a reference table.
Ok.
* services would have to provide their own filters, which first would
check
* the device driver, similar to how other DMAC drivers, e.g.,
sa11x0-dma.c, do
* this, and only then, in case of a match, call this common filter.
+ * NOTE 2: This filter function is also used in the DT case by
shdma_xlate().
+ * In that case the MID-RID value is used for slave channel filtering
and is
+ * passed to this function in the arg parameter.
*/
bool shdma_chan_filter(struct dma_chan *chan, void *arg)
{
struct shdma_chan *schan = to_shdma_chan(chan);
struct shdma_dev *sdev = to_shdma_dev(schan-dma_chan.device);
const struct shdma_ops *ops = sdev-ops;
- int slave_id = (int)arg;
+ int match = (int)arg;
int ret;
- if (slave_id 0)
+ if (match 0)
/* No slave requested - arbitrary channel */
return true;
- if (slave_id = slave_num)
+ if (!schan-dev-of_node match = slave_num)
return false;
- ret = ops-set_slave(schan, slave_id, true);
+ ret = ops-set_slave(schan, match, true);
if (ret 0)
return false;
This is complicated by the fact that you are using the same function for
two entirely different purposes. It would be easier to have a separate
filter for the DT case, rather than reusing the one that uses the slave_id
as an argument.
Hm, yes, I was considering either making 2 functions or reusing one, but
it's really the same code with only difference - the DT version wouldn't
have the slave_num check. So, I decided to use a single function
renaming slave_id to a neutral match. You really think it's become too
complex and should be copied for clarity?
I think it would be easier to understand if you have two functions, but
it's not very important. Especially if you make the new function specific
to shdma, that would be clearer.
@@ -867,6 +883,29 @@ void shdma_chan_remove(struct shdma_chan *schan)
}
EXPORT_SYMBOL(shdma_chan_remove);
+struct dma_chan *shdma_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct shdma_dev *sdev = ofdma-of_dma_data;
+ u32 id = dma_spec-args[0];
+ dma_cap_mask_t mask;
+ struct dma_chan *chan;
+
+ if (dma_spec-args_count != 1 || !sdev)
+ return NULL;
+
+ dma_cap_zero(mask);
+ /* Only slave DMA channels can be allocated via DT */
+ dma_cap_set(DMA_SLAVE, mask);
+
+ chan = dma_request_channel(mask, shdma_chan_filter, (void *)id);
+ if (chan)
+ to_shdma_chan(chan)-hw_req = id;
+
+ return chan;
+}
+EXPORT_SYMBOL(shdma_xlate);
I would suggest keeping this to the drivers/dma/sh/shdma.c file
and not exporting it. The sudma would use a different binding anyway.
Ok, can do that and then see, how different sudma's .xlate() function will
be. If it's the same we can make this common again.
I hope we can get rid of the need for calling dma_request_channel() from
xlate soon, since that is a bit silly anyway. Ideally you would just pick
the right channel of the dma_device (or the first free one, depending on
the driver) and return that from xlate.
The pdata and slave_id should really not be needed here for the lookup in
the DT
case. Is this just temporary until all slave drivers use
dmaenging_slave_config
to pass the address? That should be clarified in a comment.
Also with DT we still use platform data, passed to the driver using
auxdata. This function finds a suitable struct sh_dmae_slave_config
channel configuration entry in the platform data and returns it to the
caller. I don't think this can be avoided without carrying all the
platform data over to DT.
I think that should be done anyway. A lot of the data can just be hardcoded
in the
Re: [PATCH V5 1/3] pci: Add PCIe driver for Samsung Exynos
On Tuesday 18 June 2013, Jingoo Han wrote:
On Monday, June 17, 2013 9:45 PM, Arnd Bergmann wrote:
On Monday 17 June 2013 18:45:52 Jingoo Han wrote:
On Friday, June 14, 2013 9:54 PM, Arnd Bergmann wrote:
Please look up the documentation about inbound viewport and describe
in a code comment what it does. I /assume/ that this is how DMA accesses
from the bus get translated into AXI bus transactions. If so, you have
to let the window translate addresses from RAM. If it's something else,
then you should document what it is and how it needs to be set up.
One of our hardware engineer confirmed it.
He said that these inbound functions are unnecessary.
Also, I checked that PCIe works properly without these functions.
So, I will remove these inbound functions.
Ok, good. So DMA just gets translated 1:1 independent of the
inbound viewport? Have you tested this with PCI device using
DMA?
According to our hardware engineer,
He said that
That's correct. We tested it by doing a memory write from the device.
A device DMA is a series of memory r/w so I expect it to work same way.
Also, he thought that I already tested too, since it works after removing
the functions.
It could be that the default setting just creates a 1:1 map so that would
work, but if you tested it, that should be good enough.
I looked at the pci-mvebu driver,
Then I fixed it as the pci-mvebu driver did.
Also, I added 'global_io_offset'.
@@ -909,6 +909,12 @@ static int __init exynos_pcie_probe(struct
platform_device *pdev)
if (restype == IORESOURCE_IO) {
of_pci_range_to_resource(range, np, pp-io);
pp-io.name = I/O;
+ pp-io.start = max_t(resource_size_t,
+ PCIBIOS_MIN_IO,
+ range.pci_addr +
global_io_offset);
+ pp-io.end = min_t(resource_size_t,
+ IO_SPACE_LIMIT,
+ range.pci_addr + range.size +
global_io_offset);
pp-config.io_size = resource_size(pp-io);
pp-config.io_bus_addr = range.pci_addr;
In this case, boot message is as below:
PCI host bridge to bus :00
pci_bus :00: root bus resource [io 0x1000-0x1]
pci_bus :00: root bus resource [mem 0x40011000-0x5fff]
[.]
PCI host bridge to bus 0001:00
pci_bus 0001:00: root bus resource [io 0x1-0x2] (bus address
[0x-0x1])
pci_bus 0001:00: root bus resource [mem 0x60011000-0x7fff]
Ok, very good.
I will remove a 'remove' callback. Is it OK?
Or what should I do?
I think you should keep the remove function, but add a comment explaining that
you don't allow module unload and that in order to allow it, the remove function
will have to remove all pci buses and devices under the host bridge.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] dmaengine: Add hisilicon k3 DMA engine driver
On Tuesday 18 June 2013, zhangfei gao wrote:
On Tue, Jun 18, 2013 at 4:58 AM, Arnd Bergmann a...@arndb.de wrote:
+static struct of_dma_filter_info k3_dma_filter;
+static bool k3_dma_filter_fn(struct dma_chan *chan, void *param)
+{
+ return (*(int *)param == chan-chan_id);
+}
This filter function works only as long as there is no more than
one DMA engine in the system, which is something that needs to
be documented better. Unfortunately, providing a filter
function to be called by .xlate is currently the only way that
the dma-engine API supports, but we should really get over that.
Vinod: I think we need to add a way for a dmaengine driver to
just return one of its channels to the xlate function. The
current method is getting very silly, and it adds run-time and
code complexity without any need.
How about something like
int dma_get_slave_channel(struct dma_chan *chan)
{
/* lock against __dma_request_channel */
mutex_lock(dma_list_mutex);
if (chan-client_count == 0)
ret = dma_chan_get(chan);
else
ret = -EBUSY;
mutex_unlock(dma_list_mutex);
return ret;
}
EXPORT_SYMBOL_GPL(dma_get_slave_channel);
Want to double check here.
Device need specific channel via request line, the requirement still
can be met, right?
The driver can have a simple array of pointers that is indexed by
the request number, so you end up with something like
struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma)
{
struct k3_dma_dev *dev = ofdma-of_dma_data;
unsigned int vchan = dma_spec-args[0];
if (vchan dev-nr_channels)
return NULL;
return dma_get_slave_channel(dev-vchan[vchan]);
}
With no need to have a filter function.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem
Add clock changes for hdmi subsystem for exynos5250 SoC. These include addition of new clocks like mout_hdmi and smmu_tv, associating ID to clk_hdmiphy and some essential corrections. This set is based on kukjin's for-next branch at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. This set dependents on the following patches which add support for Exynos5420 http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg19264.html Rahul Sharma (5): clk/exynos5420: add sclk_hdmiphy to the list of special clocks clk/exynos5420: add gate clock for tv sysmmu clk/exynos5420: fix the order of parents of hdmi mux clk/exynos5420: add hdmi mux to change parents in hdmi driver clk/exynos5420: assign sclk_pixel id to pixel clock divider .../devicetree/bindings/clock/exynos5420-clock.txt |7 +++ drivers/clk/samsung/clk-exynos5420.c | 18 +++--- 2 files changed, 18 insertions(+), 7 deletions(-) -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/5] clk/exynos5420: add sclk_hdmiphy to the list of special clocks
Add sclk_hdmiphy to the list of exposed clocks. This is required
by hdmi driver to change the parent of hdmi clock.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
drivers/clk/samsung/clk-exynos5420.c |4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index 9bcc4b1..596a368 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -59,6 +59,7 @@ clock which they consume.
sclk_pwm 155
sclk_gscl_wa 156
sclk_gscl_wb 157
+ sclk_hdmiphy 158
[Peripheral Clock Gates]
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 68a96cb..0945435 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -91,7 +91,7 @@ enum exynos5420_clks {
sclk_i2s2, sclk_pcm1, sclk_pcm2, sclk_spdif, sclk_hdmi, sclk_pixel,
sclk_dp1, sclk_mipi1, sclk_fimd1, sclk_maudio0, sclk_maupcm0,
sclk_usbd300, sclk_usbd301, sclk_usbphy300, sclk_usbphy301, sclk_unipro,
- sclk_pwm, sclk_gscl_wa, sclk_gscl_wb,
+ sclk_pwm, sclk_gscl_wa, sclk_gscl_wb, sclk_hdmiphy,
/* gate clocks */
aclk66_peric = 256, uart0, uart1, uart2, uart3, i2c0, i2c1, i2c2, i2c3,
@@ -268,7 +268,7 @@ struct samsung_fixed_rate_clock
exynos5420_fixed_rate_ext_clks[] __initdata = {
/* fixed rate clocks generated inside the soc */
struct samsung_fixed_rate_clock exynos5420_fixed_rate_clks[] __initdata = {
- FRATE(none, sclk_hdmiphy, NULL, CLK_IS_ROOT, 2400),
+ FRATE(sclk_hdmiphy, sclk_hdmiphy, NULL, CLK_IS_ROOT, 2400),
FRATE(none, sclk_pwi, NULL, CLK_IS_ROOT, 2400),
FRATE(none, sclk_usbh20, NULL, CLK_IS_ROOT, 4800),
FRATE(none, mphy_refclk_ixtal24, NULL, CLK_IS_ROOT, 4800),
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 5/5] clk/exynos5420: assign sclk_pixel id to pixel clock divider
sclk_pixel is used to represent pixel clock divider on all exynos
SoCs not as a gate clock. It is queried in driver to pass as the
parent to hdmi clock while switching between parents. A new ID can
be asssigned Pixel gate clock which is currently not in use. Pixel
clock gate is default 'on'.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 59cf177..edd0696 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -434,7 +434,7 @@ struct samsung_div_clock exynos5420_div_clks[] __initdata =
{
DIV(none, dout_fimd1, mout_fimd1, DIV_DISP10, 0, 4),
DIV(none, dout_mipi1, mout_mipi1, DIV_DISP10, 16, 8),
DIV(none, dout_dp1, mout_dp1, DIV_DISP10, 24, 4),
- DIV(none, dout_hdmi_pixel, mout_pixel, DIV_DISP10, 28, 4),
+ DIV(sclk_pixel, dout_hdmi_pixel, mout_pixel, DIV_DISP10, 28, 4),
/* Audio Block */
DIV(none, dout_maudio0, mout_maudio0, DIV_MAU, 20, 4),
@@ -570,7 +570,7 @@ struct samsung_gate_clock exynos5420_gate_clks[] __initdata
= {
GATE_TOP_SCLK_DISP1, 3, CLK_SET_RATE_PARENT, 0),
GATE(sclk_hdmi, sclk_hdmi, mout_hdmi,
GATE_TOP_SCLK_DISP1, 9, CLK_SET_RATE_PARENT, 0),
- GATE(sclk_pixel, sclk_pixel, dout_hdmi_pixel,
+ GATE(none, sclk_pixel, dout_hdmi_pixel,
GATE_TOP_SCLK_DISP1, 10, CLK_SET_RATE_PARENT, 0),
GATE(sclk_dp1, sclk_dp1, dout_dp1,
GATE_TOP_SCLK_DISP1, 20, CLK_SET_RATE_PARENT, 0),
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/5] clk/exynos5420: add hdmi mux to change parents in hdmi driver
hdmi driver needs to change the parent of hdmi clock
to pixel clock or hdmiphy clock, based on the stability
of hdmiphy. This patch is exposing the mux for changing
the parent.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |5 +
drivers/clk/samsung/clk-exynos5420.c |5 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index f0b1ce0..c7a319d 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -182,6 +182,11 @@ clock which they consume.
g3d 501
smmu_tv 502
+ Mux ID
+
+
+ mout_hdmi1024
+
Example 1: An example of a clock controller node is listed below.
clock: clock-controller@0x1001 {
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 193d25e..59cf177 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -111,6 +111,9 @@ enum exynos5420_clks {
aclk333_g2d = 480, g2d, aclk333_432_gscl = 490, smmu_3aa, smmu_fimcl0,
smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d, smmu_tv,
+ /* mux clocks */
+ mout_hdmi = 1024,
+
nr_clks,
};
@@ -371,7 +374,7 @@ struct samsung_mux_clock exynos5420_mux_clks[] __initdata =
{
MUX(none, mout_mipi1, group2_p, SRC_DISP10, 16, 3),
MUX(none, mout_dp1, group2_p, SRC_DISP10, 20, 3),
MUX(none, mout_pixel, group2_p, SRC_DISP10, 24, 3),
- MUX(none, mout_hdmi, hdmi_p, SRC_DISP10, 28, 1),
+ MUX(mout_hdmi, mout_hdmi, hdmi_p, SRC_DISP10, 28, 1),
/* MAU Block */
MUX(none, mout_maudio0, maudio0_p, SRC_MAU, 28, 3),
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/5] clk/exynos5420: fix the order of parents of hdmi mux
Listing sclk_hdmiphy at 0th position in the list of parents is
causing wrong configuration in reg SRC_DISP10.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index e8be481..193d25e 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -257,7 +257,7 @@ PNAME(audio2_p) = { fin_pll, cdclk2, sclk_dpll,
sclk_mpll,
sclk_spll, sclk_ipll, sclk_epll, sclk_rpll };
PNAME(spdif_p) = { fin_pll, dout_audio0, dout_audio1, dout_audio2,
spdif_extclk, sclk_ipll, sclk_epll, sclk_rpll };
-PNAME(hdmi_p) = { sclk_hdmiphy, dout_hdmi_pixel };
+PNAME(hdmi_p) = { dout_hdmi_pixel, sclk_hdmiphy };
PNAME(maudio0_p) = { fin_pll, maudio_clk, sclk_dpll, sclk_mpll,
sclk_spll, sclk_ipll, sclk_epll, sclk_rpll };
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 4/4] arm: add basic support for Rockchip RK3066a boards
On Tuesday 18 June 2013, Heiko Stübner wrote: Side comment: I think it would be nice if the generic code did this init if a l2x0 device node was in the device tree, since the only reason to override init_machine is to do this call in addition to of_platform_populate(). Arnd said similar things in the initial version :-). Currently I'm wondering if it wouldn't be enough to call always l2x0_of_init somewhere, because it does the checking for the dt nodes itself already. The only obstacle would be platforms having the need to use special aux-values or which are currently calling the function from some other parts of the boot process (tegra inits the cache in its tegra_init_early function for example). I think we can handle this by ensuring the function only gets called once, and all platforms with special requirements call it before the common code does. I tried to understand what the requirement for non-zero argument is however and couldn't figure it out. Shouldn't we just be able to specify all the bits as DT properties all the time? Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/5] clk/exynos5420: assign sclk_pixel id to pixel clock divider
With this patch, it is at par with Exynos5250 and Exynos4 clocks
where sclk_pixel ID is assigned to a divider clock but in real,
sclk_pixel is listed under gate clocks (enum value).
Alternate to this, I can allocate a new ID, div_pixel, listed under
new category of Divider Clocks for Exyno4, 5250 and 5420.
div_pixel ID can be assigned to pixel clock dividers for all 3 SoCs.
This ID can be accessed by hdmi driver as usual. While sclk_pixel
ID can be left unused for Exyno4, 5250 as there are no pixel clock
gates. And, For 5420, sclk_pixel can optionally be used to
enable/disable the pixel clock gate.
Regards,
Rahul Sharma.
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma rahul.sha...@samsung.com wrote:
sclk_pixel is used to represent pixel clock divider on all exynos
SoCs not as a gate clock. It is queried in driver to pass as the
parent to hdmi clock while switching between parents. A new ID can
be asssigned Pixel gate clock which is currently not in use. Pixel
clock gate is default 'on'.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 59cf177..edd0696 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -434,7 +434,7 @@ struct samsung_div_clock exynos5420_div_clks[] __initdata
= {
DIV(none, dout_fimd1, mout_fimd1, DIV_DISP10, 0, 4),
DIV(none, dout_mipi1, mout_mipi1, DIV_DISP10, 16, 8),
DIV(none, dout_dp1, mout_dp1, DIV_DISP10, 24, 4),
- DIV(none, dout_hdmi_pixel, mout_pixel, DIV_DISP10, 28, 4),
+ DIV(sclk_pixel, dout_hdmi_pixel, mout_pixel, DIV_DISP10, 28, 4),
/* Audio Block */
DIV(none, dout_maudio0, mout_maudio0, DIV_MAU, 20, 4),
@@ -570,7 +570,7 @@ struct samsung_gate_clock exynos5420_gate_clks[]
__initdata = {
GATE_TOP_SCLK_DISP1, 3, CLK_SET_RATE_PARENT, 0),
GATE(sclk_hdmi, sclk_hdmi, mout_hdmi,
GATE_TOP_SCLK_DISP1, 9, CLK_SET_RATE_PARENT, 0),
- GATE(sclk_pixel, sclk_pixel, dout_hdmi_pixel,
+ GATE(none, sclk_pixel, dout_hdmi_pixel,
GATE_TOP_SCLK_DISP1, 10, CLK_SET_RATE_PARENT, 0),
GATE(sclk_dp1, sclk_dp1, dout_dp1,
GATE_TOP_SCLK_DISP1, 20, CLK_SET_RATE_PARENT, 0),
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2] of: Add more stubs for non-OF builds
Patch adds of_get_next_child and of_get_next_available_child
stubs for non-OF builds.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
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)
+
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
[PATCH 2/5] clk/exynos5420: add gate clock for tv sysmmu
Adding sysmmu clock for tv for exynos5420.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
drivers/clk/samsung/clk-exynos5420.c |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index 596a368..f0b1ce0 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -180,6 +180,7 @@ clock which they consume.
fimc_lite3 495
aclk_g3d 500
g3d 501
+ smmu_tv 502
Example 1: An example of a clock controller node is listed below.
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 0945435..e8be481 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -109,7 +109,7 @@ enum exynos5420_clks {
aclk300_gscl = 460, smmu_gscl0, smmu_gscl1, gscl_wa, gscl_wb, gscl0,
gscl1, clk_3aa, aclk266_g2d = 470, sss, slim_sss, mdma0,
aclk333_g2d = 480, g2d, aclk333_432_gscl = 490, smmu_3aa, smmu_fimcl0,
- smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d,
+ smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d, smmu_tv,
nr_clks,
};
@@ -696,6 +696,7 @@ struct samsung_gate_clock exynos5420_gate_clks[] __initdata
= {
GATE(smmu_mscl0, smmu_mscl0, aclk400_mscl, GATE_IP_MSCL, 8, 0, 0),
GATE(smmu_mscl1, smmu_mscl1, aclk400_mscl, GATE_IP_MSCL, 9, 0, 0),
GATE(smmu_mscl2, smmu_mscl2, aclk400_mscl, GATE_IP_MSCL, 10, 0, 0),
+ GATE(smmu_tv, smmu_tv, aclk200_disp1, GATE_IP_DISP1, 9, 0, 0),
};
static __initdata struct of_device_id ext_clk_match[] = {
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 5/9] ARM: OMAP: USB: Add phy binding information
Hi, On Tuesday 18 June 2013 06:05 PM, Felipe Balbi wrote: Hi, On Tue, Jun 18, 2013 at 04:43:44PM +0530, Kishon Vijay Abraham I wrote: On Tue, Jun 18, 2013 at 03:34:36PM +0530, Kishon Vijay Abraham I wrote: On Tuesday 18 June 2013 03:14 PM, Felipe Balbi wrote: On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote: In order for controllers to get PHY in case of non dt boot, the phy binding information (phy device name) should be added in the platform data of the controller. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com I would rather not pass strings around, any other way to handle this ? Why do you need to pass this string ? Our old way of binding the controller and the phy using device name started creating problems after the devices are created using PLATFORM_DEVID_AUTO. Infact non-dt boot is broken in mainline for OMAP3 platforms for which I have posted a RFC series http://www.serverphorums.com/read.php?12,708632 which also uses strings. I'm not sure of any other way to deal with this. have you checked how other frameworks handle it ? Regulator has some sort of binding in board-files, but I guess it passes the regulator name? From whatever I could make of, regulator has 3 ways to get the regulator one of which is using the binding in board-files (but it also uses device name which could create the same problem that we are facing). 1.) from dt data 2.) from _supply_ name 3.) from binding in board file (referred regulator_dev_lookup() in regulator/core.c) right, spot on. Which means we don't have a better, more elegant solution now. Let's go ahead with this. Ok. So I'll drop RFC and resend this patch series http://www.serverphorums.com/read.php?12,708632 Thanks Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 5/9] ARM: OMAP: USB: Add phy binding information
Hi, On Tue, Jun 18, 2013 at 08:25:00PM +0530, Kishon Vijay Abraham I wrote: Hi, On Tuesday 18 June 2013 06:05 PM, Felipe Balbi wrote: Hi, On Tue, Jun 18, 2013 at 04:43:44PM +0530, Kishon Vijay Abraham I wrote: On Tue, Jun 18, 2013 at 03:34:36PM +0530, Kishon Vijay Abraham I wrote: On Tuesday 18 June 2013 03:14 PM, Felipe Balbi wrote: On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote: In order for controllers to get PHY in case of non dt boot, the phy binding information (phy device name) should be added in the platform data of the controller. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com I would rather not pass strings around, any other way to handle this ? Why do you need to pass this string ? Our old way of binding the controller and the phy using device name started creating problems after the devices are created using PLATFORM_DEVID_AUTO. Infact non-dt boot is broken in mainline for OMAP3 platforms for which I have posted a RFC series http://www.serverphorums.com/read.php?12,708632 which also uses strings. I'm not sure of any other way to deal with this. have you checked how other frameworks handle it ? Regulator has some sort of binding in board-files, but I guess it passes the regulator name? From whatever I could make of, regulator has 3 ways to get the regulator one of which is using the binding in board-files (but it also uses device name which could create the same problem that we are facing). 1.) from dt data 2.) from _supply_ name 3.) from binding in board file (referred regulator_dev_lookup() in regulator/core.c) right, spot on. Which means we don't have a better, more elegant solution now. Let's go ahead with this. Ok. So I'll drop RFC and resend this patch series http://www.serverphorums.com/read.php?12,708632 please do :-) -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 02/10] pinctrl: mvebu: dove pinctrl driver
On Tue, Jun 18, 2013 at 1:36 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Maybe what we need is something like this:
static DEFINE_SPINLOCK(io_lock);
static void modifyl(u32 new, u32 mask, void __iomem *reg)
{
unsigned long flags;
u32 val;
spin_lock_irqsave(io_lock, flags);
val = readl(reg) ~mask;
val |= new | mask;
writel(val, reg);
spin_unlock_irqrestore(io_lock, flags);
}
in order to provide arbitrated access to these kinds of multifunction
registers in a safe, platform agnostic way.
Nowadays I would do the above with regmap_update_bits().
Mutual exclusion for read-modify-write of individual bits in a
register is one of those cases where doing a regmap over
a memory-mapped register range makes a lot of sense.
(drivers/mfd/syscon.c being a nice example)
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] dmaengine: Add hisilicon k3 DMA engine driver
On Tuesday 18 June 2013 22:22:17 zhangfei wrote: With no need to have a filter function. Cool, then I would like to wait for the patch. Maybe you can try to add the dma_get_slave_channel() function I proposed here as a first patch and add your driver on top. There may be issues I missed, and Vinod needs to agree to the concept first, but that would probably get his attention. Or you could send your the new interface as an add-on patch and convert your driver along with adding it. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/2] mmc: dw_mmc: Add the ability to set the ciu clock frequency
Jaehoon,
On Mon, Jun 17, 2013 at 9:51 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Doug,
I have one question for using clock-frequency.
I found the fixed-rate-clocks feature.
If we want to set clock-frequency, then can we use the fixed-rate-clocks?
i'm not sure how use the fixed-rate-clocks. but it seems to set fixed-rate
value for clock frequency.
clk_set_rate() didn't ensure to set the clock-frequency value.
I'm not sure I understand the question. I don't think that the
fixed-rate-clocks have a close relation to the clock-frequency or the
ciu clock. The fixed-rate-clock entries for a board usually specify
the root clock source for a board. For instance in exynos5250-snow
you can see:
fixed-rate-clocks {
xxti {
compatible = samsung,clock-xxti;
clock-frequency = 2400;
};
};
Other clocks in the board are derived from this clock through PLLs,
muxes, dividers, gates, etc. On 5250 we have:
fin_pll (xxti) - fout_mpll - fout_mplldiv2 - mout_mpll_fout -
sclk_mpll - sclk_mpll_user - mout_mmc1 - div_mmc1
div_mmc_pre1 - sclk_mmc1
In 5250 the ciu clock for mmc1 is sclk_mmc1, which is a simple gate.
When you enable this clock it, ungates it. The sclk_mmc1 has the
flag CLK_SET_RATE_PARENT on it. That means when you try to set the
rate it will involve the parent clock (div_mmc_pre1). The parent
clock also has CLK_SET_RATE_PARENT, so it can also involve div_mmc1.
I haven't dug through to see how the clock framework splits up divides
between div_mmc1 and div_mmc_pre1, but it's supposed to handle that.
We don't allow clk_set_rate to percolate any higher (no
CLK_SET_RATE_PARENT at mout_mmc1).
-Doug
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 02/10] pinctrl: mvebu: dove pinctrl driver
On Tue, Jun 18, 2013 at 5:11 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jun 18, 2013 at 05:02:49PM +0200, Linus Walleij wrote: Nowadays I would do the above with regmap_update_bits(). Mutual exclusion for read-modify-write of individual bits in a register is one of those cases where doing a regmap over a memory-mapped register range makes a lot of sense. (drivers/mfd/syscon.c being a nice example) So, for that solution we need to have some kind of global regmap per register or somesuch. Then you run into regmap needing a struct device - well, with a shared register, which struct device do you use, or do you have to invent one? Usually, like for syscon, you create an MFD hub which carry the regmap. That sounds more heavy-weight than is really necessary. May be so, especially if there is just one register to protect. The usefulness of MM-regmap increase with the set of registers needing to be protected. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] ARM: Kirkwood: Fix the internal register ranges translation
Although the internal register window size is 1 MiB, the previous
ranges translation for the internal register space had a size of
0x400. This was done to allow the crypto and nand node to access
the corresponding 'sram' and 'nand' decoding windows.
In order to describe the hardware more accurately, we declare the
real 1 MiB internal register space in the ranges, and add a translation
entry for the nand node to access the 'nand' window.
This commit will make future improvements on the MBus DT binding easier.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Tested on Plathome Openblocks A6 board.
arch/arm/boot/dts/kirkwood.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 8a1e3bb..910fabc 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -38,7 +38,8 @@
ocp@f100 {
compatible = simple-bus;
- ranges = 0x 0xf100 0x400
+ ranges = 0x 0xf100 0x010
+ 0xf400 0xf400 0x400
0xf500 0xf500 0x400;
#address-cells = 1;
#size-cells = 1;
@@ -171,7 +172,7 @@
ale = 1;
bank-width = 1;
compatible = marvell,orion-nand;
- reg = 0x300 0x400;
+ reg = 0xf400 0x400;
chip-delay = 25;
/* set partition map and/or chip-delay in board dts */
clocks = gate_clk 7;
--
1.8.1.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] Fix potential merge conflict for dw_apb_timer_of
Hi Pavel,
Am Dienstag, 18. Juni 2013, 17:02:44 schrieb Pavel Machek:
Hi!
The following 2 patches will eliminate the need for the patch in John
Stultz's tree. If there is to be merge of the 2 trees, then the
patch:
dw_apb_timer_of.c: Remove parts that were picoxcell-specific
can be removed from John's tree to avoid a merge-conflict.
Based on arm-soc/for-next:
PATCH[1/2] - Rename dw-apb-timer-osc and dw-apb-timer-sp bindings to
just dw-apb-timer
PATCH[2/2] - Fix user/system reporting by fixing read_sched_clock()
Pavel/Jamie: Can you take a look at these too and make sure these cover
what you were doing.
[It seems like Heiko Stübner was not aware of patches in the clock
tree, so did pretty much equivalent patch.]
Correct ... I was going after what was in linux-next and the tip.git [which I
also only saw recently at all] does not seem to be part of it.
Dinh's changes look good to me, but
[PATCH v2 4/4] clocksource: dw_apb_timer_of: use clocksource_of_init
does not exactly look nice: (I'm sorry I did not see original series,
before it was merged to -soc.). The function counts number of times it
was called, and behaves differently in each case. It is not very
traditional kernel code at the very least.
+static int num_called;
+static void __init dw_apb_timer_init(struct device_node *timer)
{
- struct device_node *event_timer, *source_timer;
-
- event_timer = of_find_matching_node(NULL, osctimer_ids);
- if (!event_timer)
- panic(No timer for clockevent);
- add_clockevent(event_timer);
-
- source_timer = of_find_matching_node(event_timer,
osctimer_ids);
- if (!source_timer)
- panic(No timer for clocksource);
- add_clocksource(source_timer);
-
- of_node_put(source_timer);
+ switch (num_called) {
+ case 0:
+ pr_debug(%s: found clockevent timer\n, __func__);
+ add_clockevent(timer);
+ of_node_put(timer);
+ break;
+ case 1:
+ pr_debug(%s: found clocksource timer\n, __func__);
+ add_clocksource(timer);
+ of_node_put(timer);
+ init_sched_clock();
+ break;
+ default:
+ break;
+ }
- init_sched_clock();
+ num_called++;
}
Heiko, can you take a look at John Stultz tree? We modified this area
already... I understand you only have one timer on your silicon?
nope, my silicon has actually three timers of this type (all of them of the
snps,dw-apb-timer-osc type ... which did change it seems).
But the clocksource also needs to provide the sched_clock on it.
Due to the multiple matching I came up with the numbering, because the of-
clocksource must match the timer ips multiple times and needs to use one as
clockevent and one as clocksource.
Would perhaps parameter on dw_apb_timer_init telling it what to do be
better solution? I don't like the num_called variable too much...
The problem I see is, how do you want to distinguish between the timer used as
clockevent and the one used as clocksource. The ip blocks are the same, so the
dt binding must also be the same, as it only describes the hardware.
And the
CLOCKSOURCE_OF_DECLARE(apb_timer, snps,dw-apb-timer-osc, dw_apb_timer_init);
of course also matches against all the timer nodes in the dt.
Heiko
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 02/10] pinctrl: mvebu: dove pinctrl driver
On Tue, Jun 18, 2013 at 05:02:49PM +0200, Linus Walleij wrote: Nowadays I would do the above with regmap_update_bits(). Mutual exclusion for read-modify-write of individual bits in a register is one of those cases where doing a regmap over a memory-mapped register range makes a lot of sense. (drivers/mfd/syscon.c being a nice example) So, for that solution we need to have some kind of global regmap per register or somesuch. Then you run into regmap needing a struct device - well, with a shared register, which struct device do you use, or do you have to invent one? That sounds more heavy-weight than is really necessary. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 0/4] ARM: OMAP2+: Panda USB Host support and DVI EDID fix
Hi Benoit Tony, The first two patches make changes to dts files to get USB host support and DVI EDID to work on Panda. The third patch should get USB host functional on uEVM. The fourth patch is a temporary workaround to create a clock alias to the USB PHY clock as it is not possible to define this via device tree. This patch is required for USB host to work on Panda and uEVM. The first 3 patches are for Benoit and the last one is for Tony. Changes in v2: - Fixed subject for patch 4 - Added regulator-always-on for Panda's USB Hub regulator cheers, -roger Roger Quadros (4): ARM: dts: omap4-panda: Add USB Host support ARM: dts: omap4-panda: Fix DVI EDID reads ARM: dts: omap5-uevm: Provide USB Host PHY clock frequency ARM: OMAP2+: Provide alias to USB PHY clock arch/arm/boot/dts/omap4-panda-common.dtsi | 69 + arch/arm/boot/dts/omap5-uevm.dts |7 +++ arch/arm/mach-omap2/board-generic.c | 23 +- 3 files changed, 98 insertions(+), 1 deletions(-) -- 1.7.4.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62 +
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 00cbaa5..7a21e8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -59,6 +59,42 @@
AFML, Line In,
AFMR, Line In;
};
+
+ /* HS USB Port 1 RESET */
+ hsusb1_reset: hsusb1_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio2 30 0; /* gpio_62 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 1 Power */
+ hsusb1_power: hsusb1_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio1 1 0;/* gpio_1 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 1 */
+ hsusb1_phy: hsusb1_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb1_reset;
+ vcc-supply = hsusb1_power;
+ /**
+* FIXME:
+* put the right clock phandle here when available
+* clocks = auxclk3;
+* clock-names = main_clk;
+*/
+ clock-frequency = 1920;
+ };
};
omap4_pmx_wkup {
@@ -83,6 +119,7 @@
mcbsp1_pins
dss_hdmi_pins
tpd12s015_pins
+ hsusbb1_pins
;
twl6030_pins: pinmux_twl6030_pins {
@@ -133,6 +170,23 @@
;
};
+ hsusbb1_pins: pinmux_hsusbb1_pins {
+ pinctrl-single,pins =
+ 0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_clk.usbb1_ulpiphy_clk */
+ 0x84 (PIN_OUTPUT | MUX_MODE4) /*
usbb1_ulpitll_stp.usbb1_ulpiphy_stp */
+ 0x86 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dir.usbb1_ulpiphy_dir */
+ 0x88 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt */
+ 0x8a (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 */
+ 0x8c (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 */
+ 0x8e (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2 */
+ 0x90 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3 */
+ 0x92 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4 */
+ 0x94 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5 */
+ 0x96 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6 */
+ 0x98 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7 */
+ ;
+ };
+
i2c1_pins: pinmux_i2c1_pins {
pinctrl-single,pins =
0xe2 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c1_scl */
@@ -283,3 +337,11 @@
mode = 3;
power = 50;
};
+
+usbhshost {
+ port1-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = hsusb1_phy;
+};
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/4] ARM: dts: omap4-panda: Fix DVI EDID reads
On Panda the +5V supply for DVI EDID is supplied by the same regulator that poweres the USB Hub. Currently, the DSS/DVI subsystem doesn't know how to manage this regulator and so DVI EDID reads will fail if USB Hub is not enabled. As a temporary fix we keep this regulator permanently enabled on boot. This fixes the DVI EDID read problem. CC: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/omap4-panda-common.dtsi |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 7a21e8e..e6e6c39 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -80,6 +80,13 @@ gpio = gpio1 1 0;/* gpio_1 */ startup-delay-us = 7; enable-active-high; + /* +* boot-on is required along with always-on as the +* regulator framework doesn't enable the regulator +* if boot-on is not there. +*/ + regulator-always-on; + regulator-boot-on; }; /* HS USB Host PHY on PORT 1 */ -- 1.7.4.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock
Till the OMAP clocks are correctly defined in device tree, use
this temporary hack to provide clock alias to the USB PHY clocks.
Without this, USB Host Ethernet will not be functional with
device tree boots on Panda and uEVM.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 23 ++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 88aa6b1..7428733 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,7 @@
#include linux/of_irq.h
#include linux/of_platform.h
#include linux/irqdomain.h
+#include linux/clk.h
#include asm/mach/arch.h
@@ -35,6 +36,21 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
{ }
};
+/*
+ * Create alias for USB host PHY clock.
+ * Remove this when clock phandle can be provided via DT
+ */
+static void __init legacy_init_ehci_clk(char *clkname)
+{
+ int ret;
+
+ ret = clk_add_alias(main_clk, NULL, clkname, NULL);
+ if (ret) {
+ pr_err(%s:Failed to add main_clk alias to %s :%d\n,
+ __func__, clkname, ret);
+ }
+}
+
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
@@ -45,10 +61,15 @@ static void __init omap_generic_init(void)
* HACK: call display setup code for selected boards to enable omapdss.
* This will be removed when omapdss supports DT.
*/
- if (of_machine_is_compatible(ti,omap4-panda))
+ if (of_machine_is_compatible(ti,omap4-panda)) {
omap4_panda_display_init_of();
+ legacy_init_ehci_clk(auxclk3_ck);
+
+ }
else if (of_machine_is_compatible(ti,omap4-sdp))
omap_4430sdp_display_init_of();
+ else if (of_machine_is_compatible(ti,omap5-uevm))
+ legacy_init_ehci_clk(auxclk1_ck);
}
#ifdef CONFIG_SOC_OMAP2420
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 3/4] ARM: dts: omap5-uevm: Provide USB Host PHY clock frequency
USB Host PHY clock on port 2 must be configured to 19.2MHz.
Provide this information.
CC: Sricharan R r.sricha...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..c0ad472 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -40,6 +40,13 @@
hsusb2_phy: hsusb2_phy {
compatible = usb-nop-xceiv;
reset-supply = hsusb2_reset;
+ /**
+ * FIXME
+ * Put the right clock phandle here when available
+ * clocks = auxclk1;
+ * clock-names = main_clk;
+ */
+ clock-frequency = 1920;
};
/* HS USB Port 3 RESET */
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
