[PATCH] of: remove the unnecessary of_node_put for of_parse_phandle_with_args()
From: Tang Yuantian yuantian.t...@freescale.com As the function itself says it is caller's responsibility to call the of_node_put(). So, remove it on success to keep the reference count correct. Signed-off-by: Tang Yuantian yuantian.t...@freescale.com --- drivers/of/base.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/of/base.c b/drivers/of/base.c index 321d3ef..e8b4c28 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -1168,9 +1168,6 @@ static int __of_parse_phandle_with_args(const struct device_node *np, out_args-args[i] = be32_to_cpup(list++); } - /* Found it! return success */ - if (node) - of_node_put(node); return 0; } -- 1.8.0 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/7] i.MX53 IPU + TVE patches
Hi Greg, Am Montag, den 08.04.2013, 10:40 -0700 schrieb Greg Kroah-Hartman: On Mon, Apr 08, 2013 at 06:04:31PM +0200, Philipp Zabel wrote: Hi, the following patches allow to use the integrated Television Encoder (TVEv2) on the i.MX53 SoC as VGA output encoder for the IPU. This is useful for the Freescale i.MX53-QSB and TQ MBa53 boards, which have VGA and DVI-I connectors, respectively. regards Philipp --- drivers/staging/imx-drm/Kconfig | 7 + drivers/staging/imx-drm/Makefile| 1 + drivers/staging/imx-drm/imx-drm-core.c | 15 +- drivers/staging/imx-drm/imx-drm.h | 14 +- drivers/staging/imx-drm/imx-tve.c | 755 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 3 + drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 55 +- drivers/staging/imx-drm/ipu-v3/ipu-di.c | 100 +++- drivers/staging/imx-drm/ipuv3-crtc.c| 11 +- 9 files changed, 932 insertions(+), 29 deletions(-) That's a lot of new features being added here, yet no work seems to be happening to move this out of the staging tree. What is left to do here, and why isn't that being worked on first, before stuff like this? the IPU code could still use a bit of testing, and I hope adding features like VGA output on common development boards will increase the amount of scrutiny this code will get. I expect the structure of the IPU drivers to change when the common display framework gets introduced at last, also requiring changes to the device tree bindings, and I'm a bit reluctant to push for mainline proper while the bindings are still not clear. regards Philipp ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/6] mfd: omap-usb-host: Device tree support for 3.10
Hi Roger, On Mon, Mar 25, 2013 at 12:42:04PM +0200, Roger Quadros wrote: Hi Samuel, I've rebased this now on top of 3.9-rc4. Please pull this into your next branch when appropriate. Thanks. The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7: Linux 3.9-rc4 (2013-03-23 16:52:44 -0700) are available in the git repository at: git://github.com/rogerq/linux.git usbhost-mfd-next Roger Quadros (5): mfd: omap-usb-host: update nports in platform_data mfd: omap-usb-host: Remove PHY reset handling code mfd: omap-usb-tll: move configuration code to omap_tll_init() mfd: omap-usb-tll: Add device tree support and binding information mfd: omap-usb-host: Add device tree support and binding information I had to apply them manually, as patches #2 and #5 do not apply. I am pushing #1, #3 and #4, please rebase 2 and 5 on top of mfd-next and resend them to me. 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: [PATCH] Documentation: gpio-reset.txt: Fix 'initially-in-reset' example
Am Donnerstag, den 04.04.2013, 09:53 +0200 schrieb Philipp Zabel:
Am Mittwoch, den 03.04.2013, 15:04 -0300 schrieb Fabio Estevam:
Fix typo in 'initially-in-reset' example.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
.../devicetree/bindings/reset/gpio-reset.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/reset/gpio-reset.txt
b/Documentation/devicetree/bindings/reset/gpio-reset.txt
index 1f203eb..8ab044c 100644
--- a/Documentation/devicetree/bindings/reset/gpio-reset.txt
+++ b/Documentation/devicetree/bindings/reset/gpio-reset.txt
@@ -26,7 +26,7 @@ gpio_reset: gpio-reset {
compatible = gpio-reset;
reset-gpios = gpio5 0 1; /* active-low */
reset-delays = 1; /* 10 ms */
- initially-in-reset: 1;
+ initially-in-reset = 1;
#reset-cells = 1;
};
Acked-by: Philipp Zabel p.za...@pengutronix.de
Disregard that, I think this fix belongs with the rest of the reset
series. I've added the patch on top of the branch at
git://git.pengutronix.de/git/pza/linux.git reset/for_v3.10
for Olof to pull.
regards
Philipp
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2] video: implement a simple framebuffer driver
On Tue, Apr 9, 2013 at 2:16 AM, Andrew Morton a...@linux-foundation.org wrote:
On Wed, 3 Apr 2013 20:39:43 -0600 Stephen Warren swar...@wwwdotorg.org
wrote:
A simple frame-buffer describes a raw memory region that may be rendered
to, with the assumption that the display hardware has already been set
up to scan out from that buffer.
This is useful in cases where a bootloader exists and has set up the
display hardware, but a Linux driver doesn't yet exist for the display
hardware.
...
+config FB_SIMPLE
+ bool Simple framebuffer support
+ depends on (FB = y) OF
It's sad that this simple little thing requires Open Firmware. Could
it be generalised in some way so that the small amount of setup info
could be provided by other means (eg, module_param) or does the
dependency go deeper than that?
Indeed. Instead of consolidating, we seem to get more of them: offb, vesafb,
efifb, ...
cfr. near the tail of drivers/video/Makefile (don't know about all of them):
# Platform or fallback drivers go here
obj-$(CONFIG_FB_UVESA)+= uvesafb.o
obj-$(CONFIG_FB_VESA) += vesafb.o
obj-$(CONFIG_FB_EFI) += efifb.o
obj-$(CONFIG_FB_VGA16)+= vga16fb.o
obj-$(CONFIG_FB_OF) += offb.o
obj-$(CONFIG_FB_BF537_LQ035) += bf537-lq035.o
obj-$(CONFIG_FB_BF54X_LQ043) += bf54x-lq043fb.o
obj-$(CONFIG_FB_BFIN_LQ035Q1) += bfin-lq035q1-fb.o
obj-$(CONFIG_FB_BFIN_T350MCQB)+= bfin-t350mcqb-fb.o
obj-$(CONFIG_FB_BFIN_7393)+= bfin_adv7393fb.o
obj-$(CONFIG_FB_MX3) += mx3fb.o
obj-$(CONFIG_FB_DA8XX)+= da8xx-fb.o
obj-$(CONFIG_FB_MXS) += mxsfb.o
obj-$(CONFIG_FB_SSD1307) += ssd1307fb.o
# the test framebuffer is last
obj-$(CONFIG_FB_VIRTUAL) += vfb.o
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFCv1 08/11] PCI: Introduce new MSI chip infrastructure
On Mon, Apr 08, 2013 at 11:28:58PM +0100, Bjorn Helgaas wrote:
On Tue, Mar 26, 2013 at 10:52 AM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:
From: Thierry Reding thierry.red...@avionic-design.de
#endif /* LINUX_MSI_H */
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2461033a..6aca43ea 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -416,6 +416,7 @@ struct pci_bus {
struct resource busn_res; /* bus numbers routed to this bus */
struct pci_ops *ops; /* configuration access functions */
+ struct msi_chip *msi; /* MSI controller */
msi seems like a too-generic name here; it suggests an interrupt or
IRQ, not a controller.
I'm not sure this is the correct place for it. Having it in the
struct pci_bus means you need arch code to fill it in, e.g., you added
it in mvebu_pcie_scan_bus() in patch 09/11. There's no good way to do
that for arches that use pci_scan_root_bus(), which is the direction
I'd like to go.
I think it probably should go in sysdata instead. That would mean you
can't really do generic weak setup/tear-down functions, because they
wouldn't know how to pull the MSI controller info out of the
arch-specific sysdata. But there are so many levels of weak-ness
going on there, maybe it would be a good thing to get rid of one :)
But generic setup/tear-down functions would allow for architecture
independent MSI controllers. This would be useful for MSI controllers that
are unrelated to PCI host controllers or a specific architecture. It would
make drivers sit more comfortably in drivers/irqchip or drivers/pci/host. Also
having the msi_chip in struct pci_bus could allow there to exist multiple
MSI controllers on a PCI fabric and is consistent with pci_ops.
Assuming the MSI controller is represented in the device tree and there is a
relationship between the controller and the host bridge
(phandle/interrupt-parent) then as Thierry suggested[1] previously you could
call
something like of_find_msi_chip_by_node(node) to locate an msi_chip from a
device node. Could this look up exist in pci_scan_root_bus via its struct
device.of_node? Perhaps pci_create_root_bus can be changed to take a parameter
for msi_chip alongside the ops parameter? The of_find_msi_chip_by_node could
walk up the device tree until it finds an MSI controller.
In the case where device tree isn't used - then I guess the weakly defined
arch_ callbacks would be replaced with the architectures existing
implementation. Or perhaps if MSI controllers are registered (msi_chip_add)
then pci_scan_root_bus could use the first controller it finds.
Also I believe pci_alloc_child_bus function would need to be changed to add
b-msi = msi to inherit msi_chip for child buses in the above patch?
Andrew Murray
[1] http://lkml.org/lkml/2013/3/25/67
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 1/8] dt: describe base reset signal binding
Hi Rob, Am Donnerstag, den 04.04.2013, 08:49 -0500 schrieb Rob Herring: On 03/28/2013 11:35 AM, Philipp Zabel wrote: From: Stephen Warren swar...@nvidia.com This binding is intended to represent the hardware reset signals present internally in most IC (SoC, FPGA, ...) designs. It consists of a binding for a reset controller device (provider), and a pair of properties, resets and reset-names, to link a device node (consumer) to its reset controller via phandle, similarly to the clock and interrupt bindings. The reset controller has all information necessary to reset the consumer device. That could be provided via device tree, or it could be implemented in hardware. The aim is to enable device drivers to request a framework API to issue a reset simply by providing their struct device pointer as the most common case. Signed-off-by: Stephen Warren swar...@nvidia.com Signed-off-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Shawn Guo shawn@linaro.org Reviewed-by: Marek Vasut ma...@denx.de Looks good. Acked-by: Rob Herring rob.herr...@calxeda.com Thank you. I'll not add the Acked-by: line to the patch itself, if that's ok, since Shawn already pulled it into his imx/soc branch. regards Philipp ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFCv1 08/11] PCI: Introduce new MSI chip infrastructure
On Mon, Apr 08, 2013 at 04:28:58PM -0600, Bjorn Helgaas wrote:
On Tue, Mar 26, 2013 at 10:52 AM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:
From: Thierry Reding thierry.red...@avionic-design.de
The new struct msi_chip is used to associated an MSI controller with a
PCI bus. It is automatically handed down from the root to its children
during bus enumeration.
This patch provides default (weak) implementations for the architecture-
specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq()
and arch_msi_check_device()) which check if a PCI device's bus has an
attached MSI chip and forward the call appropriately.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/pci/msi.c | 35 +++
drivers/pci/probe.c |1 +
include/linux/msi.h | 10 ++
include/linux/pci.h |1 +
4 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 00cc78c..fce3549 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -26,14 +26,41 @@
static int pci_msi_enable = 1;
-/* Arch hooks */
+int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
+{
+ struct msi_chip *chip = dev-bus-msi;
+
+ if (chip chip-setup_irq) {
+ int err;
+
+ err = chip-setup_irq(chip, dev, desc);
+ if (err 0)
+ return err;
+
+ irq_set_chip_data(desc-irq, chip);
+ return err;
+ }
+
+ return -EINVAL;
+}
-#ifndef arch_msi_check_device
-int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+void __weak arch_teardown_msi_irq(unsigned int irq)
{
+ struct msi_chip *chip = irq_get_chip_data(irq);
+
+ if (chip chip-teardown_irq)
+ chip-teardown_irq(chip, irq);
+}
+
+int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
I like the replacement of #ifndef arch_msi_check_device() with a
weak implementation here, but this only does half the job -- shouldn't
we remove the powerpc #define arch_msi_check_device
arch_msi_check_device at the same time?
Yes, there are a few things that can be done to cleanup the mess
around this subsequently. For instance I have a local patch which
completely removes the ARCH_SUPPORTS_MSI symbol because it isn't
useful after making the symbols weak. One other obvious item is to
convert more architectures to implement an MSI chip.
And since we're touching all the check_device() implementations, maybe
we could come up with a better name. check_device() conveys
absolutely no information about what we're checking or what the sense
of the result is. arch_msi_supported()? pcibios_msi_supported()? I
guess it should be consistent with the other arch interfaces, so
arch_*() is probably better.
At least on PowerPC the arch_msi_check_device() hook also refuses to
setup multiple MSI per device because it isn't supported. I can't think
of a better alternative than arch_msi_supported(), though so that's fine
with me.
Perhaps pcibios_msi_supported() wouldn't be so bad either. Other
architecture-specific functions already use that prefix (see the OF
support functions) and it might be good to settle on one convention for
consistency.
That said, the goal is to eventually get rid of all the arch_msi_*()
functions. The only reason they are still there is because I didn't want
to convert everything in one go. So I wanted to put the infrastructure
in place that we need to support multi-platform on ARM (which is given
by this generic MSI chip infrastructure). Later the remaining PCI
architectures can be converted to provide an msi_chip as well, at which
point the now weak implementations can become non-weak and be renamed to
something like pci_{setup,teardown,check}_msi() to make it more obvious
that they are generic.
Maybe the ugly #ifdef-ery around arch_setup_msi_irqs,
arch_teardown_msi_irqs, and arch_restore_msi_irqs could be cleaned up
similarly? Somebody worked pretty hard to obfuscate all that,
probably before weak functions were available.
I think Andrew or Jason at one point commented whether they should be
allowed to be implemented by an MSI chip. If so we could use the same
approach as for the other functions.
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b494066..9307550 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -634,6 +634,7 @@ static struct pci_bus *pci_alloc_child_bus(struct
pci_bus *parent,
child-parent = parent;
child-ops = parent-ops;
+ child-msi = parent-msi;
child-sysdata = parent-sysdata;
child-bus_flags = parent-bus_flags;
diff --git a/include/linux/msi.h b/include/linux/msi.h
index
Re: [RFCv1 08/11] PCI: Introduce new MSI chip infrastructure
On Tue, Apr 09, 2013 at 09:11:19AM +0100, Andrew Murray wrote: [...] Also I believe pci_alloc_child_bus function would need to be changed to add b-msi = msi to inherit msi_chip for child buses in the above patch? The patch already does: child-msi = parent-msi; in pci_alloc_child_bus(), the same way that ops is inherited. I have admittedly only tested this code on Tegra, but I don't see why that wouldn't be enough. Or maybe I haven't understood your question? Thierry pgp_H4hywYZFq.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFCv1 08/11] PCI: Introduce new MSI chip infrastructure
On Tue, Apr 09, 2013 at 09:22:33AM +0100, Thierry Reding wrote: On Tue, Apr 09, 2013 at 09:11:19AM +0100, Andrew Murray wrote: [...] Also I believe pci_alloc_child_bus function would need to be changed to add b-msi = msi to inherit msi_chip for child buses in the above patch? The patch already does: child-msi = parent-msi; in pci_alloc_child_bus(), the same way that ops is inherited. I have admittedly only tested this code on Tegra, but I don't see why that wouldn't be enough. Or maybe I haven't understood your question? Sorry I missed that part of your patch - that was exacatly what I was hoping to see. Andrew Murray ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring robherri...@gmail.com wrote: On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote: On 04/09/2013 12:16 AM, Stephen Warren wrote: On 04/08/2013 04:05 PM, Rob Herring wrote: On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote: According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt the #interrupt-cells property of an interrupt-controller is used to define the number of cells needed to specify a single interrupt. ... But the type is never returned so it can't be saved on the IRQ struct resource flags member. This means that drivers that need the IRQ type/level flags defined in the DT won't be able to get it. But the interrupt controllers that need the information should be able to get to it via irqd_get_trigger_type. What problem exactly are you trying to fix? What driver would use this? FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking back, I'm not sure if that was the right thing or whether I should have sent this same patch:-) Hi Stephen, I'm glad you agree :-) I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for the IRQ with irqd_get_trigger_type() but I prefer $subject because: irqd_get_trigger_type probably is not meant for outside of irqchips. Creating an irq_get_irq_type function which takes an irq number would be the right function as that does not expose struct irq_data. Ok, I can add an irqd_get_trigger_type() that just return the flags to the caller without exposing the struct irq_data and using it on the SMSC 911x driver instead using struct resource *irq_res-flags I hope networking folks understand why this change is needed in this driver to get the type/level flags for an IRQ defined on a DT... a) This works in the non-DT case with board files and filling the resources from platform data in arch/arm/mach-omap2/gpmc-smsc911x.c. So this is definitely a bug on the DT core. And hackery/abuse like this: arch/arm/mach-omap2/board-3630sdp.c:32:.flags = GPMC_MUX_ADD_DATA | IORESOURCE_IRQ_LOWLEVEL, b) I don't see why of_irq_to_resource() should discard the type/level flags when filling the IORESOURCE_IRQ if it was specified on the DT. c) We will have to change all drivers that expect to get the IRQ type flags from a IORESOURCE_IRQ struct resource. I'm not convinced that is a high number of drivers. Nearly all the occurrences of IORESOURCE_IRQ_ in drivers/ are for ISA (acpi/pnp) and drivers for ISA devices. If IORESOURCE_IRQ is just supposed to be used for ISA devices drivers that use ACPI/PnP instead DT, then of_irq_to_resource() callers should just use irq_of_parse_and_map() that returns the virtual IRQ number for an index within a controller instead of a struct resource. In fact I wonder what's the point to have an of_irq_to_resource() function at all if IORESOURCE_IRQ is not supposed to be used for devices connected through dumb buses that need a DT and the struct resource will only hold the mapped virtual IRQ number and no the IRQ flags. Rob Best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] clk: si5351: Add gapless tuning for SI5351 PLL
For gapless tuning, there is no need for PLL reset and clkout power-down
when tuning output. silabs,gapless-tuning parameter enables gapless tuning
for specific clock output.
Signed-off-by: Michal Bachraty michal.bachr...@streamunlimited.com
---
.../devicetree/bindings/clock/silabs,si5351.txt|2 ++
drivers/clk/clk-si5351.c | 27 +---
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt
b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
index cc37465..e16ab2b 100644
--- a/Documentation/devicetree/bindings/clock/silabs,si5351.txt
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -44,6 +44,8 @@ Optional child node properties:
- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
divider.
- silabs,pll-master: boolean, multisynth can change pll frequency.
+- silabs,gapless-tuning: boolean, enable gapless (glitch-free) tuning. Depends
on
+ silabs,multisynth-source parameter.
==Example==
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index e259cec..d3933a9 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -54,6 +54,7 @@ struct si5351_hw_data {
struct si5351_driver_data *drvdata;
struct si5351_parametersparams;
unsigned char num;
+ unsigned char gapless_tuning;
};
struct si5351_driver_data {
@@ -526,8 +527,10 @@ static int si5351_pll_set_rate(struct clk_hw *hw, unsigned
long rate,
(hwdata-params.p2 == 0) ? SI5351_CLK_INTEGER_MODE : 0);
/* reset pll */
- val = (hwdata-num == 0) ? SI5351_PLL_RESET_A : SI5351_PLL_RESET_B;
- si5351_set_bits(hwdata-drvdata, SI5351_PLL_RESET, val, val);
+ if (!hwdata-gapless_tuning) {
+ val = (hwdata-num == 0) ? SI5351_PLL_RESET_A :
SI5351_PLL_RESET_B;
+ si5351_set_bits(hwdata-drvdata, SI5351_PLL_RESET, val, val);
+ }
dev_dbg(hwdata-drvdata-client-dev,
%s - %s: p1 = %lu, p2 = %lu, p3 = %lu, parent_rate = %lu, rate
= %lu\n,
@@ -1064,8 +1067,9 @@ static int si5351_clkout_set_rate(struct clk_hw *hw,
unsigned long rate,
} while (1);
/* powerdown clkout */
- si5351_set_bits(hwdata-drvdata, SI5351_CLK0_CTRL + hwdata-num,
- SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
+ if (!hwdata-gapless_tuning)
+ si5351_set_bits(hwdata-drvdata, SI5351_CLK0_CTRL + hwdata-num,
+ SI5351_CLK_POWERDOWN, SI5351_CLK_POWERDOWN);
/* write output divider */
switch (hwdata-num) {
@@ -1117,6 +1121,7 @@ static void si5351_dt_setup(
struct property *prop;
const __be32 *p;
unsigned int num, val;
+ int pll = -1;
if (np == NULL)
return;
@@ -1167,6 +1172,8 @@ static void si5351_dt_setup(
dev_warn(client-dev,
unable to reparent multisynth %d to
%d\n,
num, val);
+ else
+ pll = val;
}
if (!of_property_read_u32(np, silabs,clock-source, val)) {
@@ -1178,6 +1185,15 @@ static void si5351_dt_setup(
if (!of_property_read_u32(np, clock-frequency, val))
clk_set_rate(drvdata-onecell.clks[num], val);
+
+ if (of_property_read_bool(np, silabs,gapless-tuning)) {
+ if (pll = 0) {
+ drvdata-clkout[num].gapless_tuning = 1;
+ drvdata-pll[pll].gapless_tuning = 1;
+ } else
+ dev_warn(client-dev,
+ unable to set gapless tuning);
+ }
}
}
@@ -1294,6 +1310,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
drvdata-pll[0].num = 0;
drvdata-pll[0].drvdata = drvdata;
drvdata-pll[0].hw.init = init;
+ drvdata-pll[0].gapless_tuning = 0;
memset(init, 0, sizeof(init));
init.name = si5351_pll_names[0];
init.ops = si5351_pll_ops;
@@ -1310,6 +1327,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
drvdata-pll[1].num = 1;
drvdata-pll[1].drvdata = drvdata;
drvdata-pll[1].hw.init = init;
+ drvdata-pll[1].gapless_tuning = 0;
memset(init, 0, sizeof(init));
if (drvdata-variant == SI5351_VARIANT_B) {
init.name = si5351_pll_names[2];
@@ -1380,6 +1398,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
drvdata-clkout[n].num = n;
drvdata-clkout[n].drvdata = drvdata;
drvdata-clkout[n].hw.init = init;
+ drvdata-clkout[n].gapless_tuning = 0;
Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On Tue, Apr 9, 2013 at 10:26 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring robherri...@gmail.com wrote: On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote: On 04/09/2013 12:16 AM, Stephen Warren wrote: On 04/08/2013 04:05 PM, Rob Herring wrote: On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote: According to Documentation/devicetree/bindings/interrupt-controller/interrupts.txt the #interrupt-cells property of an interrupt-controller is used to define the number of cells needed to specify a single interrupt. ... But the type is never returned so it can't be saved on the IRQ struct resource flags member. This means that drivers that need the IRQ type/level flags defined in the DT won't be able to get it. But the interrupt controllers that need the information should be able to get to it via irqd_get_trigger_type. What problem exactly are you trying to fix? What driver would use this? FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking back, I'm not sure if that was the right thing or whether I should have sent this same patch:-) Hi Stephen, I'm glad you agree :-) I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for the IRQ with irqd_get_trigger_type() but I prefer $subject because: irqd_get_trigger_type probably is not meant for outside of irqchips. Creating an irq_get_irq_type function which takes an irq number would be the right function as that does not expose struct irq_data. Ok, I can add an irqd_get_trigger_type() that just return the flags to I meant irq_get_irq_type() of course. Best regards, Javier ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] clk: add si5351 i2c common clock driver
Hi Sebastian, I posted patch for gap-less tuning. It is based on v5 of your driver. This patch was tested for tuning with 1ppm clock step. Best, Michal. On Mon, Mar 25, 2013 at 12:54 PM, Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote: On Wed, Mar 20, 2013 at 5:48 PM, Daniel Mack zon...@gmail.com wrote: On 20.03.2013 14:55, michal.bachr...@gmail.com wrote: Thanks for writing this driver! I have tested your si5351 clock driver and his tuning capabilities. It works well, it generates proper clock frequency, but when new frequency is generated, little clock gap (1ms) is generated. Si5351 datasheet and WP claims, clock tuning can be without gaps - http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5350-51-Frequency-Shifting-WP.pdf I made some tests with Si5351A chip and I found that when tuning touch only Multisynth registers, it can tune without gaps. There is no need for soft PLL reset. I found also, accessing Multisynth registers is not atomic, so there can be another frequency at output, while not all registers are written. Writing only to one register seems to be atomic. Michael, if you don't configure the clock output to modify the pll, changing output frequency will not alter pll config and there will be no reset of pll. Yeah, but limiting possible changes to the PLLs to one single register also means that you cannot offer to generate all the frequencies any more. What could probably be done is refine the algorithm so that it stays 'as close as possible' to the former values, but I'm not sure how much work that implies. Can you provide a patch against Sebastian's v3 to do that? Then it can be cleanly applied on top of the driver later. Ack. Feel free to post a patch on top of v4 now. Sebastian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/6] mfd: omap-usb-host: Device tree support for 3.10
Samuel, You had the conflicts because a patch [*] was introduced and is not required since the reset logic is being removed from the driver. Anyways, I've rebased the 2 patches on top of mfd-next, so now it shouldn't matter. cheers, -roger [*] commit 71f4b9cdfccfb82cff702fe61f4ace97a1dfb0e0 Author: Jingoo Han jg1@samsung.com Date: Wed Feb 20 18:29:30 2013 +0900 mfd: omap-usb-host: Use devm_gpio_request_one() ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] mfd: omap-usb-host: Remove PHY reset handling code
PHY reset GPIO handling will be done in the PHY driver
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/omap-usb-host.c | 28
1 files changed, 0 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index eb5db28..138ee98 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -430,24 +430,10 @@ static unsigned omap_usbhs_rev2_hostconfig(struct
usbhs_hcd_omap *omap,
static void omap_usbhs_init(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- struct usbhs_omap_platform_data *pdata = omap-pdata;
unsignedreg;
dev_dbg(dev, starting TI HSUSB Controller\n);
- if (pdata-phy_reset) {
- if (gpio_is_valid(pdata-reset_gpio_port[0]))
- devm_gpio_request_one(dev, pdata-reset_gpio_port[0],
-GPIOF_OUT_INIT_LOW, USB1 PHY reset);
-
- if (gpio_is_valid(pdata-reset_gpio_port[1]))
- devm_gpio_request_one(dev, pdata-reset_gpio_port[1],
-GPIOF_OUT_INIT_LOW, USB2 PHY reset);
-
- /* Hold the PHY in RESET for enough time till DIR is high */
- udelay(10);
- }
-
pm_runtime_get_sync(dev);
reg = usbhs_read(omap-uhh_base, OMAP_UHH_HOSTCONFIG);
@@ -476,20 +462,6 @@ static void omap_usbhs_init(struct device *dev)
dev_dbg(dev, UHH setup done, uhh_hostconfig=%x\n, reg);
pm_runtime_put_sync(dev);
- if (pdata-phy_reset) {
- /* Hold the PHY in RESET for enough time till
-* PHY is settled and ready
-*/
- udelay(10);
-
- if (gpio_is_valid(pdata-reset_gpio_port[0]))
- gpio_set_value_cansleep
- (pdata-reset_gpio_port[0], 1);
-
- if (gpio_is_valid(pdata-reset_gpio_port[1]))
- gpio_set_value_cansleep
- (pdata-reset_gpio_port[1], 1);
- }
}
/**
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/2] mfd: omap-usb-host: Add device tree support and binding information
Allows the OMAP HS USB host controller to be specified
via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Mark Rutland mark.rutl...@arm.com
---
.../devicetree/bindings/mfd/omap-usb-host.txt | 80 ++
drivers/mfd/omap-usb-host.c| 161 +++-
2 files changed, 235 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
new file mode 100644
index 000..b381fa6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -0,0 +1,80 @@
+OMAP HS USB Host
+
+Required properties:
+
+- compatible: should be ti,usbhs-host
+- reg: should contain one register range i.e. start and length
+- ti,hwmods: must contain usb_host_hs
+
+Optional properties:
+
+- num-ports: number of USB ports. Usually this is automatically detected
+ from the IP's revision register but can be overridden by specifying
+ this property. A maximum of 3 ports are supported at the moment.
+
+- portN-mode: String specifying the port mode for port N, where N can be
+ from 1 to 3. If the port mode is not specified, that port is treated
+ as unused. When specified, it must be one of the following.
+ ehci-phy,
+ehci-tll,
+ehci-hsic,
+ohci-phy-6pin-datse0,
+ohci-phy-6pin-dpdm,
+ohci-phy-3pin-datse0,
+ohci-phy-4pin-dpdm,
+ohci-tll-6pin-datse0,
+ohci-tll-6pin-dpdm,
+ohci-tll-3pin-datse0,
+ohci-tll-4pin-dpdm,
+ohci-tll-2pin-datse0,
+ohci-tll-2pin-dpdm,
+
+- single-ulpi-bypass: Must be present if the controller contains a single
+ ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1
+
+Required properties if child node exists:
+
+- #address-cells: Must be 1
+- #size-cells: Must be 1
+- ranges: must be present
+
+Properties for children:
+
+The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
+See Documentation/devicetree/bindings/usb/omap-ehci.txt and
+omap3-ohci.txt
+
+Example for OMAP4:
+
+usbhshost: usbhshost@4a064000 {
+ compatible = ti,usbhs-host;
+ reg = 0x4a064000 0x800;
+ ti,hwmods = usb_host_hs;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbhsohci: ohci@4a064800 {
+ compatible = ti,ohci-omap3, usb-ohci;
+ reg = 0x4a064800 0x400;
+ interrupt-parent = gic;
+ interrupts = 0 76 0x4;
+ };
+
+ usbhsehci: ehci@4a064c00 {
+ compatible = ti,ehci-omap, usb-ehci;
+ reg = 0x4a064c00 0x400;
+ interrupt-parent = gic;
+ interrupts = 0 77 0x4;
+ };
+};
+
+usbhshost {
+ port1-mode = ehci-phy;
+ port2-mode = ehci-tll;
+ port3-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = hsusb1_phy 0 hsusb3_phy;
+};
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 138ee98..d3b6e94 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -1,8 +1,9 @@
/**
* omap-usb-host.c - The USBHS core driver for OMAP EHCI OHCI
*
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2011-2013 Texas Instruments Incorporated - http://www.ti.com
* Author: Keshava Munegowda keshava_mgo...@ti.com
+ * Author: Roger Quadros rog...@ti.com
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 of
@@ -27,6 +28,8 @@
#include linux/platform_device.h
#include linux/platform_data/usb-omap.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_platform.h
#include omap-usb.h
@@ -137,6 +140,49 @@ static inline u8 usbhs_readb(void __iomem *base, u8 reg)
/*-*/
+/**
+ * Map 'enum usbhs_omap_port_mode' found in linux/platform_data/usb-omap.h
+ * to the device tree binding portN-mode found in
+ * 'Documentation/devicetree/bindings/mfd/omap-usb-host.txt'
+ */
+static const char * const port_modes[] = {
+ [OMAP_USBHS_PORT_MODE_UNUSED] = ,
+ [OMAP_EHCI_PORT_MODE_PHY] = ehci-phy,
+ [OMAP_EHCI_PORT_MODE_TLL] = ehci-tll,
+ [OMAP_EHCI_PORT_MODE_HSIC] = ehci-hsic,
+ [OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0] = ohci-phy-6pin-datse0,
+ [OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM] = ohci-phy-6pin-dpdm,
+ [OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0] = ohci-phy-3pin-datse0,
+ [OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM] = ohci-phy-4pin-dpdm,
+ [OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0] = ohci-tll-6pin-datse0,
+ [OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM] = ohci-tll-6pin-dpdm,
+ [OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0] = ohci-tll-3pin-datse0,
+ [OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM] =
Re: [PATCH v3] irqchip: renesas-intc-irqpin: DT binding for sense bitfield width
On Tue, Apr 09, 2013 at 01:22:29AM +0200, Laurent Pinchart wrote: Hi Guennadi, On Monday 08 April 2013 14:15:39 Guennadi Liakhovetski wrote: On Mon, 8 Apr 2013, Laurent Pinchart wrote: On Monday 08 April 2013 13:25:46 Guennadi Liakhovetski wrote: On Mon, 8 Apr 2013, Laurent Pinchart wrote: On Monday 08 April 2013 10:08:40 Guennadi Liakhovetski wrote: Most Renesas irqpin controllers have 4-bit sense fields, however, some have different widths. This patch adds a DT binding to optionally specify such non-standard values. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com --- v3: move the code to a common location, where device configuration parameters are retrieved .../interrupt-controller/renesas,intc-irqpin.txt | 13 + drivers/irqchip/irq-renesas-intc-irqpin.c |4 2 files changed, 17 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,intc- irqpin.txt diff --git a/Documentation/devicetree/bindings/interrupt- controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/ renesas,intc-irqpin.txt new file mode 100644 index 000..c6f09b7 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,int c- irqpin.txt @@ -0,0 +1,13 @@ +DT bindings for the R-/SH-Mobile irqpin controller + +Required properties: + +- compatible: has to be renesas,intc-irqpin +- #interrupt-cells: has to be 2 + +Optional properties: + +- any properties, listed in interrupts.txt in this directory, and any standard + resource allocation properties +- sense-bitfield-width: width of a single sense bitfield in the SENSE register, + if different from the default 4 bits Wouldn't it be better to define per-SoC compatible strings, and infer the sense bitfield width from that ? This is not a boolean, it is an integer, I don't think defining compatibility strings for 1, 2, 3, 4, 5,... bits is better than having one integer property. I'm not advocating for compatibility strings for a given number of bits, but for per-SoC compatibility strings from which to infer the width. For instance, if the r8a7779 has a 6-bit sense field, you would use compatible = r8a7779,intc-irqpin; and map that to 6 in the irqpin driver. I understand what you mean, still I don't think mapping N SoC-compatibility strings to various values of a single integer is better than having a single property. The way I understand (or maybe rather feel) the DT bindings philosophy is that hardware information for on-SoC IP cores that depend on the IP core version should be conveyed through the compatible property. I might be wrong though. That is also my understanding. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/6] mfd: omap-usb-host: Device tree support for 3.10
On Tue, Apr 09, 2013 at 11:39:16AM +0300, Roger Quadros wrote: Samuel, You had the conflicts because a patch [*] was introduced and is not required since the reset logic is being removed from the driver. Anyways, I've rebased the 2 patches on top of mfd-next, so now it shouldn't matter. Both patches applied, thanks a lot. 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: [PATCH 1/4] Documentation: Add memory mapped ARM architected timer binding
Hi Stephen,
On Tue, Apr 09, 2013 at 03:30:20AM +0100, Stephen Boyd wrote:
Add a binding for the arm architected timer hardware's memory
mapped interface. The mmio timer hardware is made up of one base
frame and a collection of up to 8 timer frames, where each of the
8 timer frames can have either one or two views. A frame
typically maps to a privilege level (user/kernel, hypervisor,
secure). The first view has full access to the registers within a
frame, while the second view can be restricted to particular
registers within a frame. Each frame must support a physical
timer. It's optional for a frame to support a virtual timer.
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Marc Zyngier marc.zyng...@arm.com
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
.../devicetree/bindings/arm/arch_timer.txt | 62
--
1 file changed, 59 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt
b/Documentation/devicetree/bindings/arm/arch_timer.txt
index 20746e5..69ef711 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -1,10 +1,14 @@
* ARM architected timer
-ARM cores may have a per-core architected timer, which provides per-cpu
timers.
+ARM cores may have a per-core architected timer, which provides per-cpu
timers,
+or a memory mapped architected timer, which provides up to 8 frames with a
+physical and optional virtual timer per frame.
-The timer is attached to a GIC to deliver its per-processor interrupts.
+The per-core architected timer is attached to a GIC to deliver its
+per-processor interrupts via PPIs. The memory mapped timer is attached to a
GIC
+to deliver its interrupts via SPIs.
-** Timer node properties:
+** CP15 Timer node properties:
- compatible : Should at least contain one of
arm,armv7-timer
@@ -26,3 +30,55 @@ Example:
1 10 0xf08;
clock-frequency = 1;
};
+
+** Memory mapped timer node properties
+
+- compatible : Should at least contain arm,armv7-timer-mem.
+
+- #address-cells : Must be 1.
What about LPAE systems?
How about something like the following:
#address-cells : If the ranges property is empty, the same value as the
parent node's #address-cells property. Otherwise, a
value such that the ranges property specifies a
mapping to the parent node's address space.
+
+- #size-cells : Must be 1.
+
+- ranges : Indicates parent and child bus address space are the same.
+
Similarly, what if someone wants to write a more complex mapping for some
reason?
We should be able to handle it if we use the standard accessors.
+- clock-frequency : The frequency of the main counter, in Hz. Optional.
+
+- reg : The control frame base address.
+
+Frame:
+
+- frame-id: Encoded as follows:
+ bits[3:0] frame number: 0 to 7.
+ bits[10:8] frame usage:
+ 0 - user/kernel
+ 1 - hyp
+ 2 - secure
+
Could we not just have a disabled status property for those frames claimed by a
higher level (either secure firmware or hypervisor)? Or have I missed something
here?
Then we'd just have a frame-number property, which is easier for humans to read
and understand.
+- interrupts : Interrupt list for physical and virtual timers in that order.
+ The virtual timer interrupt is optional.
+
+- reg : The first and second view base addresses in that order. The second
view
+ base address is optional.
+
+Example:
+
+ timer@f000 {
+ compatible = arm,armv7-timer-mem;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ reg = 0xf000 0x1000;
+ clock-frequency = 5000;
+ frame0@f0001000 {
+ frame-id = 0x0
+ interrupts = 0 13 0x8,
+ 0 14 0x8;
+ reg = 0xf0001000 0x1000,
+ 0xf0002000 0x1000;
+ };
+ frame1@f0003000 {
+ frame-id = 0x11
+ interrupts = 0 15 0x8;
+ reg = 0xf0003000 0x1000;
+ };
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
Mark.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3] clk: add PowerPC corenet clock driver support
From: Tang Yuantian yuantian.t...@freescale.com
This adds the clock driver for Freescale PowerPC corenet
series SoCs using common clock infrastructure.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
v3:
- remove the module author and description
v2:
- add the document for device tree clock bindings
arch/powerpc/platforms/Kconfig.cputype | 1 +
drivers/clk/Kconfig| 7 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-ppc-corenet.c | 280 +
4 files changed, 289 insertions(+)
create mode 100644 drivers/clk/clk-ppc-corenet.c
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index 18e3b76..cf065b8 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -158,6 +158,7 @@ config E500
config PPC_E500MC
bool e500mc Support
select PPC_FPU
+ select COMMON_CLK
depends on E500
help
This must be enabled for running on e500mc (and derivatives
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a47e6ee..6e2fd9c 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -63,6 +63,13 @@ config CLK_TWL6040
McPDM. McPDM module is using the external bit clock on the McPDM bus
as functional clock.
+config CLK_PPC_CORENET
+ bool Clock driver for PowerPC corenet platforms
+ depends on PPC_E500MC OF
+ ---help---
+ This adds the clock driver support for Freescale PowerPC corenet
+ platforms using common clock framework.
+
endmenu
source drivers/clk/mvebu/Kconfig
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 300d477..6720319 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -34,3 +34,4 @@ obj-$(CONFIG_X86) += x86/
obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
obj-$(CONFIG_CLK_TWL6040) += clk-twl6040.o
+obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c
new file mode 100644
index 000..a2d483f
--- /dev/null
+++ b/drivers/clk/clk-ppc-corenet.c
@@ -0,0 +1,280 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * clock driver for Freescale PowerPC corenet SoCs.
+ */
+#include linux/clk-provider.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/of.h
+#include linux/slab.h
+
+struct cmux_clk {
+ struct clk_hw hw;
+ void __iomem *reg;
+ u32 flags;
+};
+
+#define PLL_KILL BIT(31)
+#defineCLKSEL_SHIFT27
+#define CLKSEL_ADJUST BIT(0)
+#define to_cmux_clk(p) container_of(p, struct cmux_clk, hw)
+
+static void __iomem *base;
+static unsigned int clocks_per_pll;
+
+static int cmux_set_parent(struct clk_hw *hw, u8 idx)
+{
+ struct cmux_clk *clk = to_cmux_clk(hw);
+ u32 clksel;
+
+ clksel = ((idx / clocks_per_pll) 2) + idx % clocks_per_pll;
+ if (clk-flags CLKSEL_ADJUST)
+ clksel += 8;
+ clksel = (clksel 0xf) CLKSEL_SHIFT;
+ iowrite32be(clksel, clk-reg);
+
+ return 0;
+}
+
+static u8 cmux_get_parent(struct clk_hw *hw)
+{
+ struct cmux_clk *clk = to_cmux_clk(hw);
+ u32 clksel;
+
+ clksel = ioread32be(clk-reg);
+ clksel = (clksel CLKSEL_SHIFT) 0xf;
+ if (clk-flags CLKSEL_ADJUST)
+ clksel -= 8;
+ clksel = (clksel 2) * clocks_per_pll + clksel % 4;
+
+ return clksel;
+}
+
+const struct clk_ops cmux_ops = {
+ .get_parent = cmux_get_parent,
+ .set_parent = cmux_set_parent,
+};
+
+static void __init core_mux_init(struct device_node *np)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ struct cmux_clk *cmux_clk;
+ struct device_node *node;
+ int rc, count, i;
+ u32 offset;
+ const char *clk_name;
+ const char **parent_names;
+
+ rc = of_property_read_u32(np, reg, offset);
+ if (rc) {
+ pr_err(%s: could not get reg property\n, np-name);
+ return;
+ }
+
+ /* get the input clock source count */
+ count = of_property_count_strings(np, clock-names);
+ if (count 0) {
+ pr_err(%s: get clock count error\n, np-name);
+ return;
+ }
+ parent_names = kzalloc((sizeof(char *) * count), GFP_KERNEL);
+ if (!parent_names) {
+ pr_err(%s: could not allocate parent_names\n, __func__);
+ return;
+ }
+
+ for (i = 0; i count; i++)
+
[PATCH] powerpc/mpc85xx: Update the clock device tree nodes
From: Tang Yuantian yuantian.t...@freescale.com
The following SoCs will be affected: p2041, p3041, p4080,
p5020, p5040
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
* resend for review
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 62 -
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 62 -
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 100 +++-
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 8 +++
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 42 +++-
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 54 ++-
arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 4 ++
10 files changed, 337 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
index 69ac1ac..d83de62 100644
--- a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
@@ -305,9 +305,69 @@
};
clockgen: global-utilities@e1000 {
- compatible = fsl,p2041-clockgen, fsl,qoriq-clockgen-1.0;
+ compatible = fsl,p2041-clockgen, fsl,qoriq-clockgen-1.0,
+ fixed-clock;
reg = 0xe1000 0x1000;
clock-frequency = 0;
+ clock-output-names = sysclk;
+ #clock-cells = 0;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ pll0: pll0@800 {
+ #clock-cells = 1;
+ reg = 0x800;
+ compatible = fsl,core-pll-clock;
+ clocks = clockgen;
+ clock-output-names = pll0, pll0-div2, pll0-div4;
+ };
+ pll1: pll1@820 {
+ #clock-cells = 1;
+ reg = 0x820;
+ compatible = fsl,core-pll-clock;
+ clocks = clockgen;
+ clock-output-names = pll1, pll1-div2, pll1-div4;
+ };
+ mux0: mux0@0 {
+ #clock-cells = 0;
+ reg = 0x0;
+ compatible = fsl,core-mux-clock;
+ clocks = pll0 0, pll0 1, pll0 2,
+ pll1 0, pll1 1, pll1 2;
+ clock-names = pll0_0, pll0_1, pll0_2,
+ pll1_0, pll1_1, pll1_2;
+ clock-output-names = cmux0;
+ };
+ mux1: mux1@20 {
+ #clock-cells = 0;
+ reg = 0x20;
+ compatible = fsl,core-mux-clock;
+ clocks = pll0 0, pll0 1, pll0 2,
+ pll1 0, pll1 1, pll1 2;
+ clock-names = pll0_0, pll0_1, pll0_2,
+ pll1_0, pll1_1, pll1_2;
+ clock-output-names = cmux1;
+ };
+ mux2: mux2@40 {
+ #clock-cells = 0;
+ reg = 0x40;
+ compatible = fsl,core-mux-clock;
+ clocks = pll0 0, pll0 1, pll0 2,
+ pll1 0, pll1 1, pll1 2;
+ clock-names = pll0_0, pll0_1, pll0_2,
+ pll1_0, pll1_1, pll1_2;
+ clock-output-names = cmux2;
+ };
+ mux3: mux3@60 {
+ #clock-cells = 0;
+ reg = 0x60;
+ compatible = fsl,core-mux-clock;
+ clocks = pll0 0, pll0 1, pll0 2,
+ pll1 0, pll1 1, pll1 2;
+ clock-names = pll0_0, pll0_1, pll0_2,
+ pll1_0, pll1_1, pll1_2;
+ clock-output-names = cmux3;
+ };
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi
b/arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi
index 7a2697d..22f3b14 100644
--- a/arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi
@@ -81,6 +81,7 @@
cpu0: PowerPC,e500mc@0 {
device_type = cpu;
reg = 0;
+ clocks = mux0;
next-level-cache = L2_0;
L2_0: l2-cache {
next-level-cache = cpc;
@@ -89,6 +90,7 @@
cpu1: PowerPC,e500mc@1 {
device_type = cpu;
reg = 1;
+ clocks = mux1;
next-level-cache = L2_1;
L2_1:
Re: [PATCH] clk: si5351: Add gapless tuning for SI5351 PLL
On Tue, Apr 9, 2013 at 10:26 AM, Michal Bachraty michal.bachr...@streamunlimited.com wrote: For gapless tuning, there is no need for PLL reset and clkout power-down when tuning output. silabs,gapless-tuning parameter enables gapless tuning for specific clock output. Michal, does gapless tuning have any constraints? Can we use it for all rate changes or determine the need for pll reset by rate offset? Sebastian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 04/05/2013 06:58 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130405 03:44]: On 04/04/2013 07:41 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [130404 00:39]: On 04/04/2013 02:42 AM, Tony Lindgren wrote: For v3.10, let's just make sure that USB works with DT as then after v3.10 we can make omap4 DT only and get rid of estimated 7K lines of code and data. I guess this is the last piece missing for that, or are we also missing something else? For panda we just need a way to map the auxclk to the USB PHY device and the relevant dts data to get USB host working with DT. Beagle USB host should work already with DT without any changes. Can't you set up a clock alias for your device so it can find the auxclk when requesting it with the dev entry? which clock is mapped to which PHY device depends on board design and that cannot be per-determined at one place. This information needs to come from the board.dts file. OK that makes sense. There was an earlier attempt to provide a way of building clock aliases at runtime from device tree [1], but the current approach is way better [1] https://lkml.org/lkml/2013/3/12/241 For the DT clock driver if needed for v3.10, how about just do a minimal drivers/clock/omap/ that uses the standard binding? Then that driver can just do clk_get() from cclock44xx_data.c I don't understand how to do it and why it is better than the current approach. Well your approach is fine as a first step moving all the clock code, but it needs to be a real driver under drivers/clock/omap. And the DT binding needs to stay the same for the driver(s) in the long term as we start moving clocks to DT + /lib/firmware. The code needs to be there were the clock structs are defined. Currently they are in arch/arm/mach-omap2/cclock44xx_data.c for OMAP4. If this all is too late for v3.10, I suggest you just set up the right clock alias for panda with machine_is_compatible flag in board-generic.c so we get EHCI working with DT for v3.10. Then it's easy to to deal with it properly for v3.11. OK, let's do it this way for Panda for 3.10. How can that driver do clk_get() from cclock44xx_data.c? from where does it get the clk_id to pass into clk_get()? Can't you just use the clock name there to get it? In device tree we don't pass around clock names. You can either get a phandle or an index to the clock. e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt for now? And then later on we'll just move all the clocks to a combination of DT + /lib/firmware. What is the benefit of moving clock data to /lib/firmware? We could as well just move it to DT only, no? DT only clocks option is naturally available with this too. It just gets easily inefficient with such a huge number of clocks. OK. e.g. auxclk are required to be specified in DT nodes for USB PHY. Without this we can't get USB host working on Panda. OK. So if the USB PHY has a dev entry, can't you just set up a clock alias in struct omap_clk omap44xx_clks[] for it? I've explained why this can't be done above. Yes I understand now, the clock is board specific. As Rajendra points out, it seems moving entire clock data to DT is not going to happen soon. So this is the simplistic way things can work. Right but seems like we can get started there without moving them all at once. What if we provide a complete clock list instead of only auxclks in dt_clks[]? This approach is similar to arch/arm/mach-imx/clk-imx35.c Device drivers can then use them as they migrate to DT. Then later we could migrate clock data to DT, without impacting device drivers. As long as the binding stays the same in the long run too, this clock remapping approach is just fine as a starting point. And the driver needs to go to drivers/clock/omap. But in the long run we just want to get the huge amounts static data out of the kernel for clocks and hwmod data to fix things for good. In that case we need to identify what clocks need to be supported. If it is all (~200) of them, is this method good enough? cheers, -roger ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 04/05/2013 08:56 PM, Grygorii Strashko wrote:
On 04/04/2013 07:41 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130404 00:39]:
On 04/04/2013 02:42 AM, Tony Lindgren wrote:
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/of.h
#include soc.h
#include iomap.h
@@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL,cpufreq_ck,dpll_mpu_ck,CK_443X),
};
+static struct clk *scrm_clks[] = {
+auxclk0_ck,
+auxclk1_ck,
+auxclk2_ck,
+auxclk3_ck,
+auxclk4_ck,
+auxclk5_ck,
+};
Hmm I don't like the idea of specifying the auxclk both in the
cclock44xx_data.c and in DT..
Right, but till we have all clocks moved to DT we only need this
approach for general purpose clocks that are not mapped to devices
by hwmod.
For v3.10, let's just make sure that USB works with DT as then
after v3.10 we can make omap4 DT only and get rid of estimated
7K lines of code and data. I guess this is the last piece missing
for that, or are we also missing something else?
Can't you set up a clock alias for your device so it can find the
auxclk when requesting it with the dev entry?
For the DT clock driver if needed for v3.10, how about just do a
minimal drivers/clock/omap/ that uses the standard binding?
Then that driver can just do clk_get() from cclock44xx_data.c
for now? And then later on we'll just move all the clocks to a
combination of DT + /lib/firmware.
Hi Roger, Rajendra, All
Sorry that disturbing you.
Hi Grygorri,
Nothing to disturb at all ;).
I'm supporting Android OMAP4 kernels (K3.0/K3.4) and like to clarify few
points regarding this approach (having into account possible future migrations
on newer Kernels and OMAP5).
If I understand everything right, this patch series allows to create clock
binding
in DT using following syntax: clocks = aux_clks 3
Actually in v2 of the patch this would be clocks = clks 3
- does it means that in worst case there will be ~200 clock IDs defined?
I'm afraid so yes. But when I wrote this I was only thinking of generic clocks,
i.e. AUXCLKS.
So when we start talking of all clocks we might need to reconsider the approach.
- does it means that clock nodes binding using phandles (human-friendly
notation)
isn't going to be supported?
for example:
clocks = sys_clkin_ck
clocks = dss_sys_clk dss_tv_clk dss_dss_clk)
This would depend if we define the clock nodes within DT or not. From what Tony
mentioned (i.e. inefficiency) it seems that the clock nodes won't be defined
in the device tree. Then we are left with using an index.
I was horrified to think about the problems of this approach support
(in case if there would be more then ~30 IDs) - just miss with on digit
and weeks of debugging would be guaranteed.
Please, say me that i'm wrong.
It is still not written in stone so if you have a better idea we could
go that route.
cheers,
-roger
And why clock DT data can't be auto-generated like all other OMAP data
to close this questions?
Thanks.
e.g. auxclk are required to be specified in DT nodes for USB PHY.
Without this we can't get USB host working on Panda.
OK. So if the USB PHY has a dev entry, can't you just set up a
clock alias in struct omap_clk omap44xx_clks[] for it?
As Rajendra points out, it seems moving entire clock data to DT is not
going to happen soon. So this is the simplistic way things can work.
Right but seems like we can get started there without moving
them all at once.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] dmaengine: mpc512x_dma: use generic DMA DT bindings
On Mon, 08 Apr 2013 12:46:47 +0200
Lars-Peter Clausen l...@metafoo.de wrote:
...
+static struct dma_chan *mpc_dma_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ int count = dma_spec-args_count;
+ struct mpc_dma *mdma = ofdma-of_dma_data;
+ struct mpc_dma_filter_args fargs;
+ dma_cap_mask_t cap;
+
+ if (!mdma)
+ return NULL;
+
+ if (count != 1)
+ return NULL;
+
+ fargs.mdma = mdma;
+ fargs.chan_id = dma_spec-args[0];
+
+ dma_cap_zero(cap);
+ dma_cap_set(DMA_SLAVE, cap);
+
+ return dma_request_channel(cap, mpc_dma_filter, fargs);
+}
+
This is more or less the same as the generic of_dma_xlate_by_chan_id
function I posted about two weeks ago:
https://patchwork.kernel.org/patch/2331091/
Thanks. I can use the generic of_dma_xlate_by_chan_id() when above patch
will be accepted.
Anatolij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/4] ARM: davinci: fix UART clock enabling
Patch series addresses below issues: 1) Do clk_get on dev_id when there is single clock for a module 2) Fix garbled UART log with DT kernel on da850-evm. Applies on top of v3.9-rc9 of Linus's. Tested on da850-evm. Able to see proper bootup log and console on UART2. Manjunathappa, Prakash (4): ARM: davinci: uart: move to devid based clk_get ARM: davinci: da850: override device name of UART in DT kernel ARM: davinci: da850: do not specify clock_frequency for UART DT node ARM: davinci: da8xx: remove da8xx_uart_clk_enable arch/arm/boot/dts/da850.dtsi |3 - arch/arm/mach-davinci/da830.c |8 ++-- arch/arm/mach-davinci/da850.c |8 ++-- arch/arm/mach-davinci/da8xx-dt.c | 11 + arch/arm/mach-davinci/devices-da8xx.c | 40 --- arch/arm/mach-davinci/devices-tnetv107x.c | 35 ++--- arch/arm/mach-davinci/dm355.c | 48 ++- arch/arm/mach-davinci/dm365.c | 35 arch/arm/mach-davinci/dm644x.c | 48 ++- arch/arm/mach-davinci/dm646x.c | 49 +++- arch/arm/mach-davinci/include/mach/da8xx.h |2 +- arch/arm/mach-davinci/include/mach/tnetv107x.h |2 +- arch/arm/mach-davinci/serial.c | 19 ++--- arch/arm/mach-davinci/tnetv107x.c |8 ++-- 14 files changed, 233 insertions(+), 83 deletions(-) -- 1.7.4.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/4] ARM: davinci: da850: override device name of UART in DT kernel
Populate OF_DEV_AUXDATA with desired device name so as to prevent
clk_get failures.
Signed-off-by: Manjunathappa, Prakash prakash...@ti.com
---
arch/arm/mach-davinci/da8xx-dt.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 6b7a0a2..fff78a1 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -40,6 +40,9 @@ static void __init da8xx_init_irq(void)
struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(ti,davinci-i2c, 0x01c22000, i2c_davinci.1, NULL),
OF_DEV_AUXDATA(ti,davinci-wdt, 0x01c21000, watchdog, NULL),
+ OF_DEV_AUXDATA(ns16550a, 0x01c42000, serial8250.0, NULL),
+ OF_DEV_AUXDATA(ns16550a, 0x01d0c000, serial8250.1, NULL),
+ OF_DEV_AUXDATA(ns16550a, 0x01d0d000, serial8250.2, NULL),
{}
};
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/4] ARM: davinci: uart: move to dev_id based clk_get
For modules having single clock, clk_get should be done with dev_id.
But current davinci implementation handles multiple instances
of the UART devices with single platform_device_register. Hence clk_get
is based on con_id rather than dev_id, this is not correct. Do
platform_device_register for each instance and clk_get on dev_id.
Signed-off-by: Manjunathappa, Prakash prakash...@ti.com
---
arch/arm/mach-davinci/da830.c |8 ++--
arch/arm/mach-davinci/da850.c |8 ++--
arch/arm/mach-davinci/devices-da8xx.c | 40 ---
arch/arm/mach-davinci/devices-tnetv107x.c | 35 ++---
arch/arm/mach-davinci/dm355.c | 48 ++-
arch/arm/mach-davinci/dm365.c | 35
arch/arm/mach-davinci/dm644x.c | 48 ++-
arch/arm/mach-davinci/dm646x.c | 49 +++-
arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
arch/arm/mach-davinci/include/mach/tnetv107x.h |2 +-
arch/arm/mach-davinci/serial.c | 19 ++---
arch/arm/mach-davinci/tnetv107x.c |8 ++--
12 files changed, 230 insertions(+), 72 deletions(-)
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 678a54a..4a13ac9d 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -395,9 +395,9 @@ static struct clk_lookup da830_clks[] = {
CLK(NULL, tptc0,tptc0_clk),
CLK(NULL, tptc1,tptc1_clk),
CLK(davinci_mmc.0,NULL, mmcsd_clk),
- CLK(NULL, uart0,uart0_clk),
- CLK(NULL, uart1,uart1_clk),
- CLK(NULL, uart2,uart2_clk),
+ CLK(serial8250.0, NULL, uart0_clk),
+ CLK(serial8250.1, NULL, uart1_clk),
+ CLK(serial8250.2, NULL, uart2_clk),
CLK(spi_davinci.0,NULL, spi0_clk),
CLK(spi_davinci.1,NULL, spi1_clk),
CLK(NULL, ecap0,ecap0_clk),
@@ -1199,7 +1199,7 @@ static struct davinci_soc_info davinci_soc_info_da830 = {
.gpio_base = DA8XX_GPIO_BASE,
.gpio_num = 128,
.gpio_irq = IRQ_DA8XX_GPIO0,
- .serial_dev = da8xx_serial_device,
+ .serial_dev = da8xx_serial_device,
.emac_pdata = da8xx_emac_pdata,
};
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 0c4a26d..8c041e4 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -408,9 +408,9 @@ static struct clk_lookup da850_clks[] = {
CLK(NULL, tpcc1,tpcc1_clk),
CLK(NULL, tptc2,tptc2_clk),
CLK(pruss_uio,pruss,pruss_clk),
- CLK(NULL, uart0,uart0_clk),
- CLK(NULL, uart1,uart1_clk),
- CLK(NULL, uart2,uart2_clk),
+ CLK(serial8250.0, NULL, uart0_clk),
+ CLK(serial8250.1, NULL, uart1_clk),
+ CLK(serial8250.2, NULL, uart2_clk),
CLK(NULL, aintc,aintc_clk),
CLK(NULL, gpio, gpio_clk),
CLK(i2c_davinci.2,NULL, i2c1_clk),
@@ -1255,7 +1255,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
.gpio_base = DA8XX_GPIO_BASE,
.gpio_num = 144,
.gpio_irq = IRQ_DA8XX_GPIO0,
- .serial_dev = da8xx_serial_device,
+ .serial_dev = da8xx_serial_device,
.emac_pdata = da8xx_emac_pdata,
.sram_dma = DA8XX_SHARED_RAM_BASE,
.sram_len = SZ_128K,
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index fc50243..eec7132 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -67,7 +67,7 @@
void __iomem *da8xx_syscfg0_base;
void __iomem *da8xx_syscfg1_base;
-static struct plat_serial8250_port da8xx_serial_pdata[] = {
+static struct plat_serial8250_port da8xx_serial_pdata0[] = {
{
.mapbase= DA8XX_UART0_BASE,
.irq= IRQ_DA8XX_UARTINT0,
@@ -77,6 +77,11 @@ static struct plat_serial8250_port da8xx_serial_pdata[] = {
.regshift = 2,
},
{
+ .flags = 0,
+ },
+};
+static struct plat_serial8250_port da8xx_serial_pdata1[] = {
+ {
.mapbase= DA8XX_UART1_BASE,
.irq= IRQ_DA8XX_UARTINT1,
.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST |
@@ -85,6 +90,11 @@ static
[PATCH 3/4] ARM: davinci: da850: do not specify clock_frequency for UART DT node
DT kernel on da850-evm comes up with garbled UART logs. This is because
of mismatch in actual module clock rate and rate specified(clock-frequency)
in DT blob. kernel should not assume or depend on bootloaders clock
configuration, instead let it find the clock rate at runtime.
Issue discussed here before arriving on this implementation:
ARM: davinci: da850 evm: update clock rate for UART 1/2 DT nodes
https://patchwork.kernel.org/patch/2162271/
Signed-off-by: Manjunathappa, Prakash prakash...@ti.com
---
arch/arm/boot/dts/da850.dtsi |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 3ec1bda..4498375 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -66,7 +66,6 @@
serial0: serial@1c42000 {
compatible = ns16550a;
reg = 0x42000 0x100;
- clock-frequency = 15000;
reg-shift = 2;
interrupts = 25;
status = disabled;
@@ -74,7 +73,6 @@
serial1: serial@1d0c000 {
compatible = ns16550a;
reg = 0x10c000 0x100;
- clock-frequency = 15000;
reg-shift = 2;
interrupts = 53;
status = disabled;
@@ -82,7 +80,6 @@
serial2: serial@1d0d000 {
compatible = ns16550a;
reg = 0x10d000 0x100;
- clock-frequency = 15000;
reg-shift = 2;
interrupts = 61;
status = disabled;
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/4] ARM: davinci: da8xx: remove da8xx_uart_clk_enable
Serial clocks are enabled from of_platform_serial_setup:of_serial.c,
so remove davinci_serial_setup_clk from here.
Signed-off-by: Manjunathappa, Prakash prakash...@ti.com
---
arch/arm/mach-davinci/da8xx-dt.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index fff78a1..219126b 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -20,13 +20,6 @@
#define DA8XX_NUM_UARTS3
-void __init da8xx_uart_clk_enable(void)
-{
- int i;
- for (i = 0; i DA8XX_NUM_UARTS; i++)
- davinci_serial_setup_clk(i, NULL);
-}
-
static struct of_device_id da8xx_irq_match[] __initdata = {
{ .compatible = ti,cp-intc, .data = cp_intc_of_init, },
{ }
@@ -53,7 +46,6 @@ static void __init da850_init_machine(void)
of_platform_populate(NULL, of_default_bus_match_table,
da850_auxdata_lookup, NULL);
- da8xx_uart_clk_enable();
}
static const char *da850_boards_compat[] __initdata = {
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5] i.MX53 TVE clock patches
On Mon, Apr 08, 2013 at 04:46:18PM +0200, Philipp Zabel wrote: Hi, the first two are just cleanups, the following three patches are changes to the i.MX53 clock tree that are necessary to use the TVEv2 module as VGA output on the Freescale i.MX53-QSB or TQ MBa53 boards. regards Philipp --- Documentation/devicetree/bindings/clock/imx5-clock.txt | 1 - arch/arm/mach-imx/clk-imx51-imx53.c| 17 - 2 files changed, 8 insertions(+), 10 deletions(-) All 5 patches applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 7/7] staging: drm/imx: Add support for Television Encoder (TVEv2)
On Mon, Apr 08, 2013 at 06:04:38PM +0200, Philipp Zabel wrote: This driver adds support for the Television Encoder integrated on i.MX53 SoCs (TVEv2). Currently only the VGA output mode is supported, which only uses the TVDAC to generate RGB levels. HSYNC and VSYNC signals are routed directly from the IPU signal generator pins through IOMUXC. Signed-off-by: Philipp Zabel p.za...@pengutronix.de --- drivers/staging/imx-drm/Kconfig | 7 + drivers/staging/imx-drm/Makefile | 1 + drivers/staging/imx-drm/imx-tve.c | 755 ++ 3 files changed, 763 insertions(+) create mode 100644 drivers/staging/imx-drm/imx-tve.c Bindings doc is missing. Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] watchdog: at91rm9200: add DT support
Hi Joachim,
On 02/14/2013 11:02 PM, Joachim Eastwood :
Signed-off-by: Joachim Eastwood manab...@gmail.com
---
.../devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt| 9
+
drivers/watchdog/Kconfig | 2 +-
drivers/watchdog/at91rm9200_wdt.c| 9
+
3 files changed, 19 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt
diff --git
a/Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt
b/Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt
new file mode 100644
index 000..d4d86cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt
@@ -0,0 +1,9 @@
+Atmel AT91RM9200 System Timer Watchdog
+
+Required properties:
+- compatible: must be atmel,at91sam9260-wdt.
+
+Example:
+ watchdog@fd00 {
+ compatible = atmel,at91rm9200-wdt;
+ };
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 7f809fd..82ebff9 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -116,7 +116,7 @@ config ARM_SP805_WATCHDOG
config AT91RM9200_WATCHDOG
tristate AT91RM9200 watchdog
- depends on ARCH_AT91RM9200
+ depends on ARCH_AT91
This seems to trigger errors when compiling without AT91RM9200 selected:
drivers/built-in.o: In function `at91_wdt_close':
at91_adc.c:(.text+0xc9fe4): undefined reference to `at91_st_base'
drivers/built-in.o: In function `at91_wdt_write':
at91_adc.c:(.text+0xca004): undefined reference to `at91_st_base'
drivers/built-in.o: In function `at91wdt_shutdown':
at91_adc.c:(.text+0xca01c): undefined reference to `at91_st_base'
drivers/built-in.o: In function `at91wdt_suspend':
at91_adc.c:(.text+0xca038): undefined reference to `at91_st_base'
drivers/built-in.o: In function `at91_wdt_open':
at91_adc.c:(.text+0xca0cc): undefined reference to `at91_st_base'
drivers/built-in.o:at91_adc.c:(.text+0xca2c8): more undefined references to
`at91_st_base' follow
make[2]: *** [vmlinux] Error 1
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
It seems thatthis driver is not written for non-rm9200-proof compilation...
So, it can be a good idea to revert this *line* for 3.9-final: Wim, what do you
think?
Best regards,
help
Watchdog timer embedded into AT91RM9200 chips. This will reboot your
system when the timeout is reached.
diff --git a/drivers/watchdog/at91rm9200_wdt.c
b/drivers/watchdog/at91rm9200_wdt.c
index 89831ed..1c75260 100644
--- a/drivers/watchdog/at91rm9200_wdt.c
+++ b/drivers/watchdog/at91rm9200_wdt.c
@@ -24,6 +24,8 @@
#include linux/types.h
#include linux/watchdog.h
#include linux/uaccess.h
+#include linux/of.h
+#include linux/of_device.h
#include mach/at91_st.h
#define WDT_DEFAULT_TIME 5 /* seconds */
@@ -252,6 +254,12 @@ static int at91wdt_resume(struct platform_device *pdev)
#define at91wdt_resume NULL
#endif
+static const struct of_device_id at91_wdt_dt_ids[] = {
+ { .compatible = atmel,at91rm9200-wdt },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, at91_wdt_dt_ids);
+
static struct platform_driver at91wdt_driver = {
.probe = at91wdt_probe,
.remove = at91wdt_remove,
@@ -261,6 +269,7 @@ static struct platform_driver at91wdt_driver = {
.driver = {
.name = at91_wdt,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(at91_wdt_dt_ids),
},
};
--
Nicolas Ferre
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/4] Documentation: Add memory mapped ARM architected timer binding
On 04/09/13 02:08, Mark Rutland wrote: On Tue, Apr 09, 2013 at 03:30:20AM +0100, Stephen Boyd wrote: -** Timer node properties: +** CP15 Timer node properties: - compatible : Should at least contain one of arm,armv7-timer @@ -26,3 +30,55 @@ Example: 1 10 0xf08; clock-frequency = 1; }; + +** Memory mapped timer node properties + +- compatible : Should at least contain arm,armv7-timer-mem. + +- #address-cells : Must be 1. What about LPAE systems? How about something like the following: #address-cells : If the ranges property is empty, the same value as the parent node's #address-cells property. Otherwise, a value such that the ranges property specifies a mapping to the parent node's address space. Yes that is much better. I wasn't trying to preclude LPAE or 64 bit systems. + +- #size-cells : Must be 1. + +- ranges : Indicates parent and child bus address space are the same. + Similarly, what if someone wants to write a more complex mapping for some reason? We should be able to handle it if we use the standard accessors. Maybe I should just leave this part out? They are standard DT properties so I could assume DT writers know what to do. +- clock-frequency : The frequency of the main counter, in Hz. Optional. + +- reg : The control frame base address. + +Frame: + +- frame-id: Encoded as follows: +bits[3:0] frame number: 0 to 7. +bits[10:8] frame usage: +0 - user/kernel +1 - hyp +2 - secure + Could we not just have a disabled status property for those frames claimed by a higher level (either secure firmware or hypervisor)? Or have I missed something here? Using disabled status would work. I was also thinking maybe we should use a compatible string in each frame's node. Then we could match against compatible children like frame-user, frame-kernel, frame-hyp, frame-secure, frame-user-kernel, etc. It allows us flexibility if we should need to add something else in the future. Also to get the frame number, I was thinking maybe we should expand the reg property to have two address cells. Then we could have reg = 0 0xf0001000 0x1000. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
* Roger Quadros rog...@ti.com [130409 03:00]: On 04/05/2013 06:58 PM, Tony Lindgren wrote: Well your approach is fine as a first step moving all the clock code, but it needs to be a real driver under drivers/clock/omap. And the DT binding needs to stay the same for the driver(s) in the long term as we start moving clocks to DT + /lib/firmware. The code needs to be there were the clock structs are defined. Currently they are in arch/arm/mach-omap2/cclock44xx_data.c for OMAP4. But if you do just a passthrough driver then that should not be needed. If this all is too late for v3.10, I suggest you just set up the right clock alias for panda with machine_is_compatible flag in board-generic.c so we get EHCI working with DT for v3.10. Then it's easy to to deal with it properly for v3.11. OK, let's do it this way for Panda for 3.10. Yes otherwise we'll be delaying omap4 DT conversion again. How can that driver do clk_get() from cclock44xx_data.c? from where does it get the clk_id to pass into clk_get()? Can't you just use the clock name there to get it? In device tree we don't pass around clock names. You can either get a phandle or an index to the clock. e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt Yes I understand that. But the driver/clock/omap driver can just remap the DT device initially so the board specific clock is found from the clock alias table. Basically initially a passthrough driver that can be enhanced to parse DT clock bindings and load data from /lib/firmware. As long as the binding stays the same in the long run too, this clock remapping approach is just fine as a starting point. And the driver needs to go to drivers/clock/omap. But in the long run we just want to get the huge amounts static data out of the kernel for clocks and hwmod data to fix things for good. In that case we need to identify what clocks need to be supported. If it is all (~200) of them, is this method good enough? We should support any clock we need for booting the device with just DT bindings to get timers, console and rootfs working. Then we just need to load the complete set from /lib/firmware. It seems that the binding can be the same for all the clocks. For now, we can just use the standard clock binding and do the remapping in the clock driver. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] Documentation: dt: update properties in TI GPMC NAND example
The GPMC timing properties for device-tree have been updated by adding a -ns or -ps suffix to indicate the units of time the property represents. Therefore, update the timing property names for TI GPMC NAND example. Signed-off-by: Jon Hunter jon-hun...@ti.com --- .../devicetree/bindings/mtd/gpmc-nand.txt | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index e7f8d7e..6a983c1 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -56,20 +56,20 @@ Example for an AM33xx board: nand-bus-width = 16; ti,nand-ecc-opt = bch8; - gpmc,sync-clk = 0; - gpmc,cs-on = 0; - gpmc,cs-rd-off = 44; - gpmc,cs-wr-off = 44; - gpmc,adv-on = 6; - gpmc,adv-rd-off = 34; - gpmc,adv-wr-off = 44; - gpmc,we-off = 40; - gpmc,oe-off = 54; - gpmc,access = 64; - gpmc,rd-cycle = 82; - gpmc,wr-cycle = 82; - gpmc,wr-access = 40; - gpmc,wr-data-mux-bus = 0; + gpmc,sync-clk-ps = 0; + gpmc,cs-on-ns = 0; + gpmc,cs-rd-off-ns = 44; + gpmc,cs-wr-off-ns = 44; + gpmc,adv-on-ns = 6; + gpmc,adv-rd-off-ns = 34; + gpmc,adv-wr-off-ns = 44; + gpmc,we-off-ns = 40; + gpmc,oe-off-ns = 54; + gpmc,access-ns = 64; + gpmc,rd-cycle-ns = 82; + gpmc,wr-cycle-ns = 82; + gpmc,wr-access-ns = 40; + gpmc,wr-data-mux-bus-ns = 0; #address-cells = 1; #size-cells = 1; -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
* Tony Lindgren t...@atomide.com [130409 09:54]: * Roger Quadros rog...@ti.com [130409 03:00]: On 04/05/2013 06:58 PM, Tony Lindgren wrote: Can't you just use the clock name there to get it? In device tree we don't pass around clock names. You can either get a phandle or an index to the clock. e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt Yes I understand that. But the driver/clock/omap driver can just remap the DT device initially so the board specific clock is found from the clock alias table. Basically initially a passthrough driver that can be enhanced to parse DT clock bindings and load data from /lib/firmware. Actually probably the driver/clock/omap can even do even less initially. There probably even no need to remap clocks there. As long as the DT clock driver understands that a board specific auxclk is specified in the DT it can just call clk_add_alias() so the driver will get the right auxclk from cclock44xx_data.c. Then other features can be added later on like to allocate a clock entirely based on the binding etc. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
Dear Arnd Bergmann, On Tue, 9 Apr 2013 00:14:06 +0200, Arnd Bergmann wrote: pcie-realio.type = IORESOURCE_IO; pcie-realio.start = max(PCIBIOS_MIN_IO, range-pci_addr); pcie-realio.end = max(IO_SPACE_LIMIT, range-pci_addr + range-size); Shouldn't this last line be using min() so that we guarantee we don't have an I/O region that goes beyond IO_SPACE_LIMIT? Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv7 08/17] pci: PCIe driver for Marvell Armada 370/XP systems
On Tuesday 09 April 2013, Thomas Petazzoni wrote: Dear Arnd Bergmann, On Tue, 9 Apr 2013 00:14:06 +0200, Arnd Bergmann wrote: pcie-realio.type = IORESOURCE_IO; pcie-realio.start = max(PCIBIOS_MIN_IO, range-pci_addr); pcie-realio.end = max(IO_SPACE_LIMIT, range-pci_addr + range-size); Shouldn't this last line be using min() so that we guarantee we don't have an I/O region that goes beyond IO_SPACE_LIMIT? Yes, of course. Sorry for not typing what I was thinking ;-) Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [GIT PULL] dt: run C pre-processor on *.dts, create some standard headers
On 04/05/2013 01:46 PM, Stephen Warren wrote: Rob, it might be worth keeping this in a separate branch in linux-next so you can pull it out if it causes any issues. I've been using these patches for quite a while now, but there's always opportunity for surprises on architectures I don't use. I did just fix a bug when building with O= a few days back, hence the V2 that I posted as patches. Pulled into my for-next branch. Rob This branch enhances the support for running dtc on device tree files. A dedicated directory is created for header files that provide constants for device-tree bindings. The kbuild dependency script processor is enhanced to support processing the dependency outputs from multiple separate commands at once. The kbuild dtc rule is modified so that the C pre-processor is always applied when compiling any device tree. Some standard headers are created which define common constants for GPIO, IRQ, and ARM GIC device tree bindings. The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: Linux 3.9-rc1 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.10-dtc-cpp-chroot-std-headers for you to fetch changes up to 4be505d4fc7a07371a2b658469ca1dda3ca3: ARM: dt: create a DT header for the GIC Stephen Warren (7): kbuild: create an include chroot for DT bindings kbuild: fixdep: support concatenated dep files kbuild: cmd_dtc_cpp: extract deps from both gcc -E and dtc kbuild: always run gcc -E on *.dts, remove cmd_dtc_cpp ARM: dt: add header to define GPIO flags ARM: dt: add header to define IRQ flags ARM: dt: create a DT header for the GIC arch/arm/boot/dts/include/dt-bindings |1 + include/dt-bindings/gpio/gpio.h | 15 +++ .../dt-bindings/interrupt-controller/arm-gic.h | 22 + include/dt-bindings/interrupt-controller/irq.h | 19 scripts/Makefile.lib| 17 ++-- scripts/basic/fixdep.c | 93 -- 6 files changed, 125 insertions(+), 42 deletions(-) create mode 12 arch/arm/boot/dts/include/dt-bindings create mode 100644 include/dt-bindings/gpio/gpio.h create mode 100644 include/dt-bindings/interrupt-controller/arm-gic.h create mode 100644 include/dt-bindings/interrupt-controller/irq.h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver
Wolfram, Thanks for your review! On Mon, Apr 8, 2013 at 3:26 AM, Wolfram Sang w...@the-dreams.de wrote: I'd like to have the bindings more generic. They should allow for n possible masters IMO. It doesn't need to be implemented right now, but it should be possible to add that later. Done. Left code as only handling one other master (as you suggested) since it has been tested that way and there are no known users with more than one other master. Code will give an error if it encounters a device tree with more than one master. I wonder about a more generic name. i2c-arb-gpio-challenge.* maybe? Done. I'd like to drop the specific terms of AP and EC and just talk about multiple masters. Done. An array based approach like in the i2c-mux-gpio driver would be more generic. Just mention that the driver only supports 2 entries at the moment. Done. Mentioned that some drivers may only support one other master (rather than describing the current state of the kernel code) since bindings should make sense even outside of a single driver, I think. Grant, I assume it is okay to introduce these generic bindings? You are thinking that Grant wouldn't like the names I chose, or that bindings of this type might not be OK? The scheme as it stands is pretty close to what Grant suggested himself here https://patchwork.kernel.org/patch/1877311/. I did drop the bus-arbitration- prefix from the ones he wrote up since it seemed redundant to have that prefix on all properties of a node that's only for bus arbitration anyway. I can add them back in if you think it's better. I think Grant only had that prefix in his proposed bindings because that was the name of the properties in Naveen's patch (where the bus arbitration was bolted on to the i2c bus and thus needed differentiation). +config I2C_ARBITRATOR_CROS_EC + tristate GPIO-based I2C arbitrator used on exynos5250-snow + depends on GENERIC_GPIO OF + help + If you say yes to this option, support will be included for an + I2C multimaster arbitration scheme using GPIOs that is used in + the Samsung ARM Chromebook (exynos5250-snow). + + This driver can also be built as a module. If so, the module + will be called i2c-arbitrator-cros-ec. + This text could be more generic then, too. Done. + /* We only support probing from device tree; no platform_data */ + if (WARN_ON(!np)) + return -ENODEV; Too much WARN_ON for my taste. Sure. I've removed them all and put dev_err() messages everywhere as other mux drivers seem to. I'd been of the mindset that there was no need for verbose error messages and extra complexity for uncommon cases like this, but I can see the benefit of describing exactly what went wrong in the kernel log. Please let me know if there's any other fixes needed. -Doug ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
where masters need to claim the bus with a GPIO before they can start
a transcation. This should generally only be used when standard I2C
multimaster isn't appropriate for some reason (errata/bugs).
This driver is based on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree. The current incarnation as a
mux driver is as suggested by Grant Likely. See
https://patchwork.kernel.org/patch/1877311/ for some history.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Stephen Warren swar...@nvidia.com
---
Changes in v5:
- Renamed as per Wolfram Sang.
- Avoid references to AP and EC.
- Bindings are now generic and could support N other masters; code
still only supports one other master.
- Replaced all instances of WARN_ON with error messages.
- Left Stephen's Reviewed-by from v4 since changes aren't huge, but
please yell if you want it removed or don't like something about the
new code; removed Naveen's Tested-by for now.
Changes in v4: None
Changes in v3:
- Handle of_find_i2c_adapter_by_node() failure more properly by
changing init order.
- Don't warn on -EPROBE_DEFER from calls that could return it.
- Move to module_platform_driver(). As we pull in parts of the system
that rely on devices under this i2c bus we'll need to make sure they
can handle the fact that they'll be initted later now.
Changes in v2:
- Renamed to i2c-arb-gpio-challenge.
- Documented microsecond properties as optional; removed
bus-arbitration prefix since it was just extra wordy.
- Split GPIOs into two properties to make it cleaner.
- Capitalized I2C in freeform text.
- Get 'active low' from device tree.
.../bindings/i2c/i2c-arb-gpio-challenge.txt| 80 +++
drivers/i2c/muxes/Kconfig | 11 +
drivers/i2c/muxes/Makefile | 2 +
drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 252 +
4 files changed, 345 insertions(+)
create mode 100644
Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
create mode 100644 drivers/i2c/muxes/i2c-arb-gpio-challenge.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
new file mode 100644
index 000..726e099
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
@@ -0,0 +1,80 @@
+GPIO-based I2C Arbitration
+==
+This uses GPIO lines to arbitrate who is the master of an I2C bus in a
+multimaster situation.
+
+In many cases using GPIOs to arbitrate is not needed and a design can use
+the standard I2C multi-master rules. Using GPIOs is generally useful in
+the case where there is a device on the bus that has errata and/or bugs
+that makes standard multimaster mode not feasible.
+
+
+Algorithm:
+
+All masters on the bus have a 'bus claim' line which is an output that the
+others can see. These are all active low with pull-ups enabled. We'll
+describe these lines as:
+
+- OUR_CLAIM: output from us signaling to other hosts that we want the bus
+- THEIR_CLAIMS: output from others signaling that they want the bus
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also. A detailed explanation is best
+done with an example.
+
+Let's say we want to claim the bus. We:
+1. Assert OUR_CLAIM.
+2. Waits a little bit for the other sides to notice (slew time, say 10
+ microseconds).
+3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we
are
+ done.
+4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arb-gpio-challenge
+- our-claim-gpio: The GPIO that we use to claim the bus.
+- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
+ Note that some implementations may only support a single other master.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 5
us.
+
+
+Example:
+ i2c@12CA {
+ compatible = acme,some-i2c-device;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
+
+ i2c-arbitrator {
+ compatible = i2c-arb-gpio-challenge;
+ #address-cells = 1;
+ #size-cells
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 10:43-20130409, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130409 09:54]:
* Roger Quadros rog...@ti.com [130409 03:00]:
On 04/05/2013 06:58 PM, Tony Lindgren wrote:
Can't you just use the clock name there to get it?
In device tree we don't pass around clock names. You can either get
a phandle or an index to the clock.
e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
Yes I understand that. But the driver/clock/omap driver can just
remap the DT device initially so the board specific clock is
found from the clock alias table. Basically initially a passthrough
driver that can be enhanced to parse DT clock bindings and load
data from /lib/firmware.
Actually probably the driver/clock/omap can even do even less
initially. There probably even no need to remap clocks there.
As long as the DT clock driver understands that a board specific
auxclk is specified in the DT it can just call clk_add_alias() so
the driver will get the right auxclk from cclock44xx_data.c.
Then other features can be added later on like to allocate a
clock entirely based on the binding etc.
I did try to have an implementation for cpufreq using clock nodes.
unfortunately, device tree wont let me have arguments of strings :(
So, I am unable to do clock = clk mpu_dpll;
instead, I am forced to do clock = clk 249;
Here is an attempt on beagleXM - adds every clock node to the list.
Tons of un-necessary prints added to give an idea - see log:
http://pastebin.com/F9A2zSTr
Would an cleaned up version be good enough as a step #1 of transition?
From 7d373bdb9e9549c1b6ba1775a8dfd96ebe78abfb Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 26 Mar 2013 10:23:27 +
Subject: [PATCH] OMAP: add devicetree support for clock nodes.
Dummy patch based on Roger's original idea
Nyet-Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap3.dtsi |5 ++
arch/arm/boot/dts/omap34xx.dtsi |2 +
arch/arm/mach-omap2/cclock3xxx_data.c |3 +-
arch/arm/mach-omap2/cclock44xx_data.c |3 +-
arch/arm/mach-omap2/pm.c | 11 +++-
drivers/clk/Kconfig |6 ++
drivers/clk/Makefile |2 +
drivers/clk/ti.c | 100 +
include/linux/clk/ti.h| 30 ++
9 files changed, 157 insertions(+), 5 deletions(-)
create mode 100644 drivers/clk/ti.c
create mode 100644 include/linux/clk/ti.h
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 3344f05..a08990d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -73,6 +73,11 @@
ti,hwmods = counter_32k;
};
+ clks: clocks {
+ compatible = ti,clock;
+ #clock-cells = 1;
+ };
+
intc: interrupt-controller@4820 {
compatible = ti,omap2-intc;
interrupt-controller;
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 75ed4ae..93c2621 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -23,6 +23,8 @@
60 135
;
clock-latency = 30; /* From legacy driver */
+ clocks = clks 249; /* index to cpufreq_ck */
+ clock-names = cpu;
};
};
};
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..d5d5ef5 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -22,6 +22,7 @@
#include linux/clk-private.h
#include linux/list.h
#include linux/io.h
+#include linux/clk/ti.h
#include soc.h
#include iomap.h
@@ -3574,7 +3575,7 @@ int __init omap3xxx_clk_init(void)
for (c = omap3xxx_clks; c omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
c++)
if (c-cpu cpu_clkflg) {
- clkdev_add(c-lk);
+ ti_clk_node_add(c-lk);
if (!__clk_init(NULL, c-lk.clk))
omap2_init_clk_hw_omap_clocks(c-lk.clk);
}
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 0c6834a..338ef64 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/clk/ti.h
#include soc.h
#include iomap.h
@@ -1697,7 +1698,7 @@ int __init omap4xxx_clk_init(void)
for (c = omap44xx_clks; c omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
c++) {
if (c-cpu cpu_clkflg
Re: [PATCH] watchdog: at91rm9200: add DT support
Hi All, diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 7f809fd..82ebff9 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -116,7 +116,7 @@ config ARM_SP805_WATCHDOG config AT91RM9200_WATCHDOG tristate AT91RM9200 watchdog - depends on ARCH_AT91RM9200 + depends on ARCH_AT91 This seems to trigger errors when compiling without AT91RM9200 selected: drivers/built-in.o: In function `at91_wdt_close': at91_adc.c:(.text+0xc9fe4): undefined reference to `at91_st_base' drivers/built-in.o: In function `at91_wdt_write': at91_adc.c:(.text+0xca004): undefined reference to `at91_st_base' drivers/built-in.o: In function `at91wdt_shutdown': at91_adc.c:(.text+0xca01c): undefined reference to `at91_st_base' drivers/built-in.o: In function `at91wdt_suspend': at91_adc.c:(.text+0xca038): undefined reference to `at91_st_base' drivers/built-in.o: In function `at91_wdt_open': at91_adc.c:(.text+0xca0cc): undefined reference to `at91_st_base' drivers/built-in.o:at91_adc.c:(.text+0xca2c8): more undefined references to `at91_st_base' follow make[2]: *** [vmlinux] Error 1 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 It seems thatthis driver is not written for non-rm9200-proof compilation... So, it can be a good idea to revert this *line* for 3.9-final: Wim, what do you think? If this triggers compile error, then this indeed needs to get fixed. I'll do the necessary tomorrow. Kind regards, Wim. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 00/19] PCIe support for the Armada 370 and Armada XP SoCs
Hello, This series of patches introduces PCIe support for the Marvell Armada 370 and Armada XP. In the future, we plan to extend the driver to cover Kirkwood platforms, and possibly other Marvell EBU platforms as well. Here is the current status of the different patches: * Patches 1-5 are awaiting a formal Acked-by from the Device Tree maintainers. Patches 1-3 are the new version of the OF PCI range parsing functions from Andrew Murray, which he worked on after the comments from Rob Herring. Patches 4 and 5 are much more trivial and have been around since many versions of this series. * Patch 6 and 10, that are touching drivers/pci/ have been formally Acked-by Bjorn Helgaas, the PCI maintainer. * Patch 7, which is touching arch/arm/kernel, has been merged by Russell King already, see http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7683/1. * Patches 8 and 9 are touching drivers/clk, and are awaiting an Acked-by from Mike Turquette. However, they are fairly trivial patches, so they shouldn't cause too much problem. * All the other patches touch mvebu-specific things, either mach-mvebu or the related Device Tree files or defconfig, so it's up to the Marvell maintainers to pick them up. This patch set depends on: * The arm-soc/mvebu/cleanup branch in Arnd and Olof arm-soc tree * [PATCH v3 for 3.10] Introduce a Marvell EBU MBus driver http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/156883.html For easier testing, the code has been pushed to: git://github.com/MISL-EBU-System-SW/mainline-public.git marvell-pcie-v8 This PATCHv8 follows: * PATCHv7, sent on March, 27th 2013 * PATCHv6, sent on March, 26st 2013 * PATCHv5, sent on March, 21st 2013 * PATCHv4, sent on March, 8th 2013 * PATCHv3, sent on February, 12th 2013 * PATCHv2, sent on January, 28th 2013 * RFCv1, sent on December, 7th 2012 Changes between v7 and v8: * In the patch introducing the drivers/pci/host directory, add an empty drivers/pci/host/Makefile to ensure that the kernel still build. This Makefile will actually gets its first useful line when the Marvell PCIe driver gets added. Noted by Neil Greatorex. * Remove bogus (and useless) CFLAGS in drivers/pci/host/Makefile for the compilation of the Marvell PCIe driver. Noticed by Bjorn Helgaas. * Added missing parenthesis in the definition of the PCIE_BAR_CTRL_OFF macro. Noticed by Bjorn Helgaas. * Make mvebu_pcie_link_up() return 'bool' instead of 'int'. Suggested by Bjorn Helgaas. * Change mvebu_pcie_link_up(), mvebu_pcie_set_local_bus_nr(), mvebu_pcie_setup_wins(), mvebu_pcie_setup_hw(), mvebu_pcie_hw_rd_conf(), mvebu_pcie_hw_wr_conf() so that they take a 'struct mvebu_pcie_port *' instead of a 'void __iomem *' as first argument. The base address of the PCIe interface register are available using the 'base' field of 'struct mvebu_pcie_port'. Suggested by Bjorn Helgaas. * Fixed multi-line comments that should have been one line comments. Noticed by Bjorn Helgaas. * Fixed a for() loop in mvebu_pcie_setup_wins() to use the more conventional 'ii 3' ending condition instead of 'i = 2'. Suggested by Bjorn Helgaas. * Add a #define instead of an hardcoded magic value when enabling interrupts A-D in mvebu_pcie_setup_hw(). Suggested by Bjorn Helgaas. * Add a PCIE_CONF_ADDR() to simplify the code in mvebu_pcie_hw_rd_conf() and mvebu_pcie_hw_wr_conf(). Suggested by Bjorn Helgaas. * Clarify the comments in mvebu_pcie_handle_iobase_change() and mvebu_pcie_handle_membase_change() so that it is clear we look at the new iobase/iolimit (respectively membase/memlimit) values. Suggested by Bjorn Helgaas. * Replace mvebu_pcie_find_port_by_bus() and mvebu_pcie_find_port_by_devfn() by a single mvebu_pcie_find_port() function, and simplify the mvebu_pcie_rd_conf() and mvebu_pcie_wr_conf() functions. Suggested by Bjorn Helgaas. * Fix the computation of the real I/O resource start and end addresses, according to the suggestions of Arnd Bergmann and Jason Gunthorpe. * Remove the MASK/OFFS definition, and use definitions more in the style of pci_regs.h. Suggested by Bjorn Helgaas. * Integrate the latest version of 'of/pci: Provide support for parsing PCI DT ranges property' from Andrew Murray, fixed according to the review of Rob Herring. * Added the Acked-by tags from Bjorn Helgaas on the PCI patches. Changes between v6 and v7: * Use assigned-addresses in the DT subnodes for the MMIO PCIe registers, in order to align with what Thierry is doing on the Tegra PCIe driver. * Added empty 'ranges;' properties in the subnodes, as requested by Arnd. Note that due to this, it is not possible to remove the #address-cells and #size-cells properties from the subnodes, as Jason Gunthorpe requested, otherwise the DT compiler complains with: Warning (ranges_format): /soc/pcie-controller/pcie@1,0 has
[PATCHv8 01/19] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
From: Andrew Murray andrew.mur...@arm.com
The pci_process_bridge_OF_ranges function, used to parse the ranges
property of a PCI host device, is found in both Microblaze and PowerPC
architectures. These implementations are nearly identical. This patch
moves this common code to a common place.
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: mon...@monstr.eu
Cc: b...@kernel.crashing.org
Cc: pau...@samba.org
Cc: Ralf Baechle r...@linux-mips.org
---
arch/microblaze/include/asm/pci-bridge.h |5 +-
arch/microblaze/pci/pci-common.c | 192
arch/powerpc/include/asm/pci-bridge.h|5 +-
arch/powerpc/kernel/pci-common.c | 192
drivers/of/of_pci.c | 200 ++
include/linux/of_pci.h |4 +
6 files changed, 206 insertions(+), 392 deletions(-)
diff --git a/arch/microblaze/include/asm/pci-bridge.h
b/arch/microblaze/include/asm/pci-bridge.h
index cb5d397..5783cd6 100644
--- a/arch/microblaze/include/asm/pci-bridge.h
+++ b/arch/microblaze/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
#include linux/pci.h
#include linux/list.h
#include linux/ioport.h
+#include linux/of_pci.h
struct device_node;
@@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller *hose,
extern struct pci_controller *pci_find_hose_for_OF_device(
struct device_node *node);
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
- struct device_node *dev, int primary);
-
/* Allocate free a PCI host bridge structure */
extern struct pci_controller *pcibios_alloc_controller(struct device_node
*dev);
extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 9ea521e..2735ad9 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int
bar,
*end = rsrc-end - offset;
}
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the ranges property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- * - We can only cope with one IO space range and up to 3 Memory space
- * ranges. However, some machines (thanks Apple !) tend to split their
- * space into lots of small contiguous ranges. So we have to coalesce.
- *
- * - We can only cope with all memory ranges having the same offset
- * between CPU addresses and PCI addresses. Unfortunately, some bridges
- * are setup for a large 1:1 mapping along with a small window which
- * maps PCI address 0 to some arbitrary high address of the CPU space in
- * order to give access to the ISA memory hole.
- * The way out of here that I've chosen for now is to always set the
- * offset based on the first resource found, then override it if we
- * have a different offset and the previous was set by an ISA hole.
- *
- * - Some busses have IO space not starting at 0, which causes trouble with
- * the way we do our IO resource renumbering. The code somewhat deals with
- * it for 64 bits but I would expect problems on 32 bits.
- *
- * - Some 32 bits platforms such as 4xx can have physical space larger than
- * 32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
- struct device_node *dev, int primary)
-{
- const u32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(dev);
- int np = pna + 5;
- int memno = 0, isa_hole = -1;
- u32 pci_space;
- unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
- unsigned long long isa_mb = 0;
- struct resource *res;
-
- pr_info(PCI host bridge %s %s ranges:\n,
- dev-full_name, primary ? (primary) : );
-
- /* Get ranges property */
- ranges = of_get_property(dev, ranges, rlen);
- if (ranges == NULL)
- return;
-
- /* Parse it */
- pr_debug(Parsing ranges property...\n);
- while ((rlen -= np * 4) = 0) {
- /* Read next ranges element */
- pci_space = ranges[0];
- pci_addr = of_read_number(ranges + 1, 2);
- cpu_addr = of_translate_address(dev, ranges + 3);
[PATCHv8 02/19] of/pci: Provide support for parsing PCI DT ranges property
From: Andrew Murray andrew.mur...@arm.com
This patch factors out common implementation patterns to reduce
overall kernel code and provide a means for host bridge drivers to
directly obtain struct resources from the DT's ranges property without
relying on architecture specific DT handling. This will make it easier
to write archiecture independent host bridge drivers and mitigate
against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_parser parser;
struct of_pci_range range;
if (of_pci_range_parser(parser, np))
; //no ranges property
for_each_of_pci_range(parser, range) {
/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags
alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(range, np, res);
*/
}
Additionally the implementation takes care of adjacent ranges and
merges them into a single range (as was the case with powerpc and
microblaze).
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: mon...@monstr.eu
Cc: b...@kernel.crashing.org
Cc: pau...@samba.org
Cc: Ralf Baechle r...@linux-mips.org
---
drivers/of/address.c | 63 +
drivers/of/of_pci.c| 112
include/linux/of_address.h | 42 +
3 files changed, 145 insertions(+), 72 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..e87f45e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,69 @@ int of_pci_address_to_resource(struct device_node *dev,
int bar,
return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
}
EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser-node = node;
+ parser-pna = of_n_addr_cells(node);
+ parser-np = parser-pna + na + ns;
+
+ parser-range = of_get_property(node, ranges, rlen);
+ if (parser-range == NULL)
+ return -ENOENT;
+
+ parser-end = parser-range + rlen / sizeof(__be32);
+
+ return 0;
+}
+
+struct of_pci_range *of_pci_process_ranges(struct of_pci_range_parser *parser,
+ struct of_pci_range *range)
+{
+ const int na = 3, ns = 2;
+
+ if (!parser-range || parser-range + parser-np parser-end)
+ return NULL;
+
+ range-pci_space = be32_to_cpup(parser-range);
+ range-flags = of_bus_pci_get_flags(parser-range);
+ range-pci_addr = of_read_number(parser-range + 1, ns);
+ range-cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ range-size = of_read_number(parser-range + parser-pna + na, ns);
+
+ parser-range += parser-np;
+
+ /* Now consume following elements while they are contiguous */
+ while (parser-range + parser-np = parser-end) {
+ u32 flags, pci_space;
+ u64 pci_addr, cpu_addr, size;
+
+ pci_space = be32_to_cpup(parser-range);
+ flags = of_bus_pci_get_flags(parser-range);
+ pci_addr = of_read_number(parser-range + 1, ns);
+ cpu_addr = of_translate_address(parser-node,
+ parser-range + na);
+ size = of_read_number(parser-range + parser-pna + na, ns);
+
+ if (flags != range-flags)
+ break;
+ if (pci_addr != range-pci_addr + range-size ||
+ cpu_addr != range-cpu_addr + range-size)
+ break;
+
+ range-size += size;
+ parser-range += parser-np;
+ }
+
+ return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_process_ranges);
+
#endif /* CONFIG_PCI */
/*
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 9dd8a10..ebb408b 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -82,67 +82,43 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
void pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary)
{
- const u32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(dev);
- int np = pna + 5;
int memno = 0, isa_hole = -1;
- u32 pci_space;
- unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
unsigned long long isa_mb = 0;
struct resource *res;
+
[PATCHv8 03/19] of/pci: mips: convert to common of_pci_range_parser
From: Andrew Murray andrew.mur...@arm.com
This patch converts the pci_load_of_ranges function to use the new
common of_pci_range_parser.
Signed-off-by: Andrew Murray andrew.mur...@arm.com
Signed-off-by: Liviu Dudau liviu.du...@arm.com
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: mon...@monstr.eu
Cc: b...@kernel.crashing.org
Cc: pau...@samba.org
Cc: Ralf Baechle r...@linux-mips.org
---
arch/mips/pci/pci.c | 50 --
1 file changed, 16 insertions(+), 34 deletions(-)
diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
index 0872f12..bee49a4 100644
--- a/arch/mips/pci/pci.c
+++ b/arch/mips/pci/pci.c
@@ -122,51 +122,33 @@ static void pcibios_scanbus(struct pci_controller *hose)
#ifdef CONFIG_OF
void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
{
- const __be32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(node);
- int np = pna + 5;
+ struct of_pci_range_range range;
+ struct of_pci_range_parser parser;
+ u32 res_type;
pr_info(PCI host bridge %s ranges:\n, node-full_name);
- ranges = of_get_property(node, ranges, rlen);
- if (ranges == NULL)
- return;
hose-of_node = node;
- while ((rlen -= np * 4) = 0) {
- u32 pci_space;
+ if (of_pci_range_parser(parser, node))
+ return;
+
+ for_each_of_pci_range(parser, range) {
struct resource *res = NULL;
- u64 addr, size;
-
- pci_space = be32_to_cpup(ranges[0]);
- addr = of_translate_address(node, ranges + 3);
- size = of_read_number(ranges + pna + 3, 2);
- ranges += np;
- switch ((pci_space 24) 0x3) {
- case 1: /* PCI IO space */
+
+ res_type = range.flags IORESOURCE_TYPE_BITS;
+ if (res_type == IORESOURCE_IO) {
pr_info( IO 0x%016llx..0x%016llx\n,
- addr, addr + size - 1);
+ range.addr, range.addr + range.size - 1);
hose-io_map_base =
- (unsigned long)ioremap(addr, size);
+ (unsigned long)ioremap(range.addr, range.size);
res = hose-io_resource;
- res-flags = IORESOURCE_IO;
- break;
- case 2: /* PCI Memory space */
- case 3: /* PCI 64 bits Memory space */
+ } else if (res_type == IORESOURCE_MEM) {
pr_info( MEM 0x%016llx..0x%016llx\n,
- addr, addr + size - 1);
+ range.addr, range.addr + range.size - 1);
res = hose-mem_resource;
- res-flags = IORESOURCE_MEM;
- break;
- }
- if (res != NULL) {
- res-start = addr;
- res-name = node-full_name;
- res-end = res-start + size - 1;
- res-parent = NULL;
- res-sibling = NULL;
- res-child = NULL;
}
+ if (res != NULL)
+ of_pci_range_to_resource(range, node, res);
}
}
#endif
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 04/19] of/pci: Add of_pci_get_devfn() function
From: Thierry Reding thierry.red...@avionic-design.de
This function can be used to parse the device and function number from a
standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
the returned value obtain the device and function numbers respectively.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
drivers/of/of_pci.c| 34 +-
include/linux/of_pci.h |1 +
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index ebb408b..b77e8d8 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -9,14 +9,15 @@
#endif
static inline int __of_pci_pci_compare(struct device_node *node,
- unsigned int devfn)
+ unsigned int data)
{
- unsigned int size;
- const __be32 *reg = of_get_property(node, reg, size);
+ int devfn;
- if (!reg || size 5 * sizeof(__be32))
+ devfn = of_pci_get_devfn(node);
+ if (devfn 0)
return 0;
- return ((be32_to_cpup(reg[0]) 8) 0xff) == devfn;
+
+ return devfn == data;
}
struct device_node *of_pci_find_child_device(struct device_node *parent,
@@ -208,3 +209,26 @@ void pci_process_bridge_OF_ranges(struct pci_controller
*hose,
}
}
#endif
+
+/**
+ * of_pci_get_devfn() - Get device and function numbers for a device node
+ * @np: device node
+ *
+ * Parses a standard 5-cell PCI resource and returns an 8-bit value that can
+ * be passed to the PCI_SLOT() and PCI_FUNC() macros to extract the device
+ * and function numbers respectively. On error a negative error code is
+ * returned.
+ */
+int of_pci_get_devfn(struct device_node *np)
+{
+ unsigned int size;
+ const __be32 *reg;
+
+ reg = of_get_property(np, reg, size);
+
+ if (!reg || size 5 * sizeof(__be32))
+ return -EINVAL;
+
+ return (be32_to_cpup(reg) 8) 0xff;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_devfn);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index e56182f..302aca0 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,6 +11,7 @@ int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq
*out_irq);
struct device_node;
struct device_node *of_pci_find_child_device(struct device_node *parent,
unsigned int devfn);
+int of_pci_get_devfn(struct device_node *np);
void pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary);
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 06/19] pci: infrastructure to add drivers in drivers/pci/host
As agreed by the community, PCI host drivers will now be stored in drivers/pci/host. This commit adds this directory and the related Kconfig/Makefile changes to allow new drivers to be added in this directory. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Acked-by: Bjorn Helgaas bhelg...@google.com --- drivers/pci/Kconfig |2 ++ drivers/pci/Makefile |3 +++ drivers/pci/host/Kconfig |4 drivers/pci/host/Makefile |1 + 4 files changed, 10 insertions(+) create mode 100644 drivers/pci/host/Kconfig create mode 100644 drivers/pci/host/Makefile diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 6d51aa6..ac45398 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -119,3 +119,5 @@ config PCI_IOAPIC config PCI_LABEL def_bool y if (DMI || ACPI) select NLS + +source drivers/pci/host/Kconfig diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index 0c3efcf..6ebf5bf 100644 --- a/drivers/pci/Makefile +++ b/drivers/pci/Makefile @@ -67,3 +67,6 @@ obj-$(CONFIG_XEN_PCIDEV_FRONTEND) += xen-pcifront.o obj-$(CONFIG_OF) += of.o ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG + +# PCI host controller drivers +obj-y += host/ diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig new file mode 100644 index 000..cc3a1af --- /dev/null +++ b/drivers/pci/host/Kconfig @@ -0,0 +1,4 @@ +menu PCI host controller drivers + depends on PCI + +endmenu diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile new file mode 100644 index 000..636bc1a --- /dev/null +++ b/drivers/pci/host/Makefile @@ -0,0 +1 @@ +# intentionally empty -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 07/19] arm: pci: add a align_resource hook
The PCI specifications says that an I/O region must be aligned on a 4
KB boundary, and a memory region aligned on a 1 MB boundary.
However, the Marvell PCIe interfaces rely on address decoding windows
(which allow to associate a range of physical addresses with a given
device). For PCIe memory windows, those windows are defined with a 1
MB granularity (which matches the PCI specs), but PCIe I/O windows can
only be defined with a 64 KB granularity, so they have to be 64 KB
aligned. We therefore need to tell the PCI core about this special
alignement requirement.
The PCI core already calls pcibios_align_resource() in the ARM PCI
core, specifically for such purposes. So this patch extends the ARM
PCI core so that it calls a -align_resource() hook registered by the
PCI driver, exactly like the existing -map_irq() and -swizzle()
hooks.
A particular PCI driver can register a align_resource() hook, and do
its own specific alignement, depending on the specific constraints of
the underlying hardware.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Russell King li...@arm.linux.org.uk
---
arch/arm/include/asm/mach/pci.h | 11 +++
arch/arm/kernel/bios32.c|6 ++
2 files changed, 17 insertions(+)
diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index 5cf2e97..7d2c3c8 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -30,6 +30,11 @@ struct hw_pci {
void(*postinit)(void);
u8 (*swizzle)(struct pci_dev *dev, u8 *pin);
int (*map_irq)(const struct pci_dev *dev, u8 slot, u8 pin);
+ resource_size_t (*align_resource)(struct pci_dev *dev,
+ const struct resource *res,
+ resource_size_t start,
+ resource_size_t size,
+ resource_size_t align);
};
/*
@@ -51,6 +56,12 @@ struct pci_sys_data {
u8 (*swizzle)(struct pci_dev *, u8 *);
/* IRQ mapping
*/
int (*map_irq)(const struct pci_dev *, u8, u8);
+ /* Resource alignement requirements
*/
+ resource_size_t (*align_resource)(struct pci_dev *dev,
+ const struct resource *res,
+ resource_size_t start,
+ resource_size_t size,
+ resource_size_t align);
void*private_data; /* platform controller private data
*/
};
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index a1f73b5..b2ed73c 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -462,6 +462,7 @@ static void pcibios_init_hw(struct hw_pci *hw, struct
list_head *head)
sys-busnr = busnr;
sys-swizzle = hw-swizzle;
sys-map_irq = hw-map_irq;
+ sys-align_resource = hw-align_resource;
INIT_LIST_HEAD(sys-resources);
if (hw-private_data)
@@ -574,6 +575,8 @@ char * __init pcibios_setup(char *str)
resource_size_t pcibios_align_resource(void *data, const struct resource *res,
resource_size_t size, resource_size_t align)
{
+ struct pci_dev *dev = data;
+ struct pci_sys_data *sys = dev-sysdata;
resource_size_t start = res-start;
if (res-flags IORESOURCE_IO start 0x300)
@@ -581,6 +584,9 @@ resource_size_t pcibios_align_resource(void *data, const
struct resource *res,
start = (start + align - 1) ~(align - 1);
+ if (sys-align_resource)
+ return sys-align_resource(dev, res, start, size, align);
+
return start;
}
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 08/19] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
The Armada 370 has two gatable clocks for each PCIe interface, and we
want both of them to be enabled. We therefore make one of the two
clocks a child of the other, as we did for the sataX and sataXlnk
clocks on Armada XP.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/mvebu/clk-gating-ctrl.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c
b/drivers/clk/mvebu/clk-gating-ctrl.c
index ebf141d..b35785a 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -119,8 +119,8 @@ static const struct mvebu_soc_descr __initconst
armada_370_gating_descr[] = {
{ pex1_en, NULL, 2 },
{ ge1, NULL, 3 },
{ ge0, NULL, 4 },
- { pex0, NULL, 5 },
- { pex1, NULL, 9 },
+ { pex0, pex0_en, 5 },
+ { pex1, pex1_en, 9 },
{ sata0, NULL, 15 },
{ sdio, NULL, 17 },
{ tdm, NULL, 25 },
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 09/19] clk: mvebu: add more PCIe clocks for Armada XP
The current revision of the datasheet only mentions the gatable clocks
for the PCIe 0.0, 0.1, 0.2 and 0.3 interfaces, and forgot to mention
the ones for the PCIe 1.0, 1.1, 1.2, 1.3, 2.0 and 3.0
interfaces. After confirmation with Marvell engineers, this patch adds
the missing gatable clocks for those PCIe interfaces.
It also changes the name of the previously existing PCIe gatable
clocks, in order to match the naming using the datasheets.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/mvebu/clk-gating-ctrl.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c
b/drivers/clk/mvebu/clk-gating-ctrl.c
index b35785a..2f03723 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -137,10 +137,14 @@ static const struct mvebu_soc_descr __initconst
armada_xp_gating_descr[] = {
{ ge2, NULL, 2 },
{ ge1, NULL, 3 },
{ ge0, NULL, 4 },
- { pex0, NULL, 5 },
- { pex1, NULL, 6 },
- { pex2, NULL, 7 },
- { pex3, NULL, 8 },
+ { pex00, NULL, 5 },
+ { pex01, NULL, 6 },
+ { pex02, NULL, 7 },
+ { pex03, NULL, 8 },
+ { pex10, NULL, 9 },
+ { pex11, NULL, 10 },
+ { pex12, NULL, 11 },
+ { pex13, NULL, 12 },
{ bp, NULL, 13 },
{ sata0lnk, NULL, 14 },
{ sata0, sata0lnk, 15 },
@@ -152,6 +156,8 @@ static const struct mvebu_soc_descr __initconst
armada_xp_gating_descr[] = {
{ xor0, NULL, 22 },
{ crypto, NULL, 23 },
{ tdm, NULL, 25 },
+ { pex20, NULL, 26 },
+ { pex30, NULL, 27 },
{ xor1, NULL, 28 },
{ sata1lnk, NULL, 29 },
{ sata1, sata1lnk, 30 },
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 10/19] pci: PCIe driver for Marvell Armada 370/XP systems
This driver implements the support for the PCIe interfaces on the
Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
cover earlier families of Marvell SoCs, such as Dove, Orion and
Kirkwood.
The driver implements the hw_pci operations needed by the core ARM PCI
code to setup PCI devices and get their corresponding IRQs, and the
pci_ops operations that are used by the PCI core to read/write the
configuration space of PCI devices.
Since the PCIe interfaces of Marvell SoCs are completely separate and
not linked together in a bus, this driver sets up an emulated PCI host
bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
interface.
In addition, this driver enumerates the different PCIe slots, and for
those having a device plugged in, it sets up the necessary address
decoding windows, using the new armada_370_xp_alloc_pcie_window()
function from mach-mvebu/addr-map.c.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Bjorn Helgaas bhelg...@google.com
---
.../devicetree/bindings/pci/mvebu-pci.txt | 220 +
drivers/pci/host/Kconfig |4 +
drivers/pci/host/Makefile |2 +-
drivers/pci/host/pci-mvebu.c | 879
4 files changed, 1104 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt
create mode 100644 drivers/pci/host/pci-mvebu.c
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
new file mode 100644
index 000..eb69d92
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -0,0 +1,220 @@
+* Marvell EBU PCIe interfaces
+
+Mandatory properties:
+- compatible: one of the following values:
+marvell,armada-370-pcie
+marvell,armada-xp-pcie
+- #address-cells, set to 3
+- #size-cells, set to 2
+- #interrupt-cells, set to 1
+- bus-range: PCI bus numbers covered
+- device_type, set to pci
+- ranges: ranges for the PCI memory and I/O regions, as well as the
+ MMIO registers to control the PCIe interfaces.
+
+In addition, the Device Tree node must have sub-nodes describing each
+PCIe interface, having the following mandatory properties:
+- reg: used only for interrupt mapping, so only the first four bytes
+ are used to refer to the correct bus number and device number.
+- assigned-addresses: reference to the MMIO registers used to control
+ this PCIe interface.
+- clocks: the clock associated to this PCIe interface
+- marvell,pcie-port: the physical PCIe port number
+- status: either disabled or okay
+- device_type, set to pci
+- #address-cells, set to 3
+- #size-cells, set to 2
+- #interrupt-cells, set to 1
+- ranges, empty property.
+- interrupt-map-mask and interrupt-map, standard PCI properties to
+ define the mapping of the PCIe interface to interrupt numbers.
+
+and the following optional properties:
+- marvell,pcie-lane: the physical PCIe lane number, for ports having
+ multiple lanes. If this property is not found, we assume that the
+ value is 0.
+
+Example:
+
+pcie-controller {
+ compatible = marvell,armada-xp-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ ranges = 0x8200 0 0xd004 0xd004 0 0x2000 /* Port 0.0
registers */
+ 0x8200 0 0xd0042000 0xd0042000 0 0x2000 /* Port 2.0
registers */
+ 0x8200 0 0xd0044000 0xd0044000 0 0x2000 /* Port 0.1
registers */
+ 0x8200 0 0xd0048000 0xd0048000 0 0x2000 /* Port 0.2
registers */
+ 0x8200 0 0xd004c000 0xd004c000 0 0x2000 /* Port 0.3
registers */
+ 0x8200 0 0xd008 0xd008 0 0x2000 /* Port 1.0
registers */
+ 0x8200 0 0xd0082000 0xd0082000 0 0x2000 /* Port 3.0
registers */
+ 0x8200 0 0xd0084000 0xd0084000 0 0x2000 /* Port 1.1
registers */
+ 0x8200 0 0xd0088000 0xd0088000 0 0x2000 /* Port 1.2
registers */
+ 0x8200 0 0xd008c000 0xd008c000 0 0x2000 /* Port 1.3
registers */
+ 0x8200 0 0xe000 0xe000 0 0x0800 /*
non-prefetchable memory */
+ 0x8100 0 0 0xe800 0 0x0010; /*
downstream I/O */
+
+ pcie@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd004 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;
+ interrupt-map = 0 0 0 0 mpic 58;
+ marvell,pcie-port = 0;
+ marvell,pcie-lane = 0;
+ clocks = gateclk 5;
+
[PATCHv8 11/19] arm: mvebu: PCIe support is now available on mvebu
Now that the PCIe driver for mvebu has been integrated and all its relevant dependencies, we can mark the ARCH_MVEBU platform has MIGHT_HAVE_PCI, which allows to select the PCI bus support if needed. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- arch/arm/mach-mvebu/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index c3715a5..d353249 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -14,6 +14,8 @@ config ARCH_MVEBU select MVEBU_CLK_CPU select MVEBU_CLK_GATING select MVEBU_MBUS + select MIGHT_HAVE_PCI + select PCI_QUIRKS if PCI if ARCH_MVEBU -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 12/19] arm: mvebu: add PCIe Device Tree informations for Armada 370
The Armada 370 SoC has two 1x PCIe 2.0 interfaces, so we add the
necessary Device Tree informations to make these interfaces availabel.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-370.dtsi | 51 +
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 8188d13..2d9f8d6 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -153,5 +153,56 @@
clocks = coreclk 0;
};
+ pcie-controller {
+ compatible = marvell,armada-370-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ reg = 0xd004 0x2000, 0xd008 0x2000;
+
+ reg-names = pcie0.0, pcie1.0;
+
+ ranges = 0x8200 0 0xd004 0xd004 0
0x2000 /* Port 0.0 registers */
+ 0x8200 0 0xd008 0xd008 0
0x2000 /* Port 1.0 registers */
+ 0x8200 0 0xe000 0xe000 0
0x0800 /* non-prefetchable memory */
+ 0x8100 0 0 0xe800 0
0x0010; /* downstream I/O */
+
+ pcie@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd004 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;
+ interrupt-map = 0 0 0 0 mpic 58;
+ marvell,pcie-port = 0;
+ marvell,pcie-lane = 0;
+ clocks = gateclk 5;
+ status = disabled;
+ };
+
+ pcie@2,0 {
+ device_type = pci;
+ assigned-addresses = 0x82002800 0 0xd008 0
0x2000;
+ reg = 0x1000 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0 mpic 62;
+ marvell,pcie-port = 1;
+ marvell,pcie-lane = 0;
+ clocks = gateclk 9;
+ status = disabled;
+ };
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 13/19] arm: mvebu: add PCIe Device Tree informations for Armada XP
The Armada XP SoCs have multiple PCIe interfaces. The MV78230 has 2
PCIe units (one 4x or quad 1x, the other 1x only), the MV78260 has 3
PCIe units (two 4x or quad 1x and one 4x/1x), the MV78460 has 4 PCIe
units (two 4x or quad 1x and two 4x/1x). We therefore add the
necessary Device Tree informations to make those PCIe interfaces
usable.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 104 +
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 122 +++
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 188 ++
3 files changed, 414 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f56c405..c2c7845 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -76,5 +76,109 @@
#interrupts-cells = 2;
interrupts = 87, 88, 89;
};
+
+ /*
+* MV78230 has 2 PCIe units Gen2.0: One unit can be
+* configured as x4 or quad x1 lanes. One unit is
+* x4/x1.
+*/
+ pcie-controller {
+ compatible = marvell,armada-xp-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ ranges = 0x8200 0 0xd004 0xd004 0
0x2000 /* Port 0.0 registers */
+ 0x8200 0 0xd0042000 0xd0042000 0
0x2000 /* Port 2.0 registers */
+ 0x8200 0 0xd0044000 0xd0044000 0
0x2000 /* Port 0.1 registers */
+ 0x8200 0 0xd0048000 0xd0048000 0
0x2000 /* Port 0.2 registers */
+ 0x8200 0 0xd004c000 0xd004c000 0
0x2000 /* Port 0.3 registers */
+ 0x8200 0 0xe000 0xe000 0
0x0800 /* non-prefetchable memory */
+ 0x8100 0 0 0xe800 0
0x0010; /* downstream I/O */
+
+ pcie@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd004 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;
+ interrupt-map = 0 0 0 0 mpic 58;
+ marvell,pcie-port = 0;
+ marvell,pcie-lane = 0;
+ clocks = gateclk 5;
+ status = disabled;
+ };
+
+ pcie@2,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd0044000 0
0x2000;
+ reg = 0x1000 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0 mpic 59;
+ marvell,pcie-port = 0;
+ marvell,pcie-lane = 1;
+ clocks = gateclk 6;
+ status = disabled;
+ };
+
+ pcie@3,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd0048000 0
0x2000;
+ reg = 0x1800 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+ ranges;
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0 0 0 0 mpic 60;
+ marvell,pcie-port = 0;
+ marvell,pcie-lane = 2;
+ clocks = gateclk 7;
+ status = disabled;
+ };
+
+ pcie@4,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd004c000 0
0x2000;
+ reg = 0x2000 0 0 0 0;
+ #address-cells = 3;
+
[PATCHv8 14/19] arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4
The PlatHome OpenBlocks AX3-4 has an internal mini-PCIe slot that can
be used to plug mini-PCIe devices. We therefore enable the PCIe
interface that corresponds to this slot.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 +
1 file changed, 9 insertions(+)
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 3818a82..5a748bd 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -139,5 +139,14 @@
usb@d0051000 {
status = okay;
};
+
+ pcie-controller {
+ status = okay;
+ /* Internal mini-PCIe connector */
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 15/19] arm: mvebu: PCIe Device Tree informations for Armada XP DB
The Marvell evaluation board (DB) for the Armada XP SoC has 6
physicals full-size PCIe slots, so we enable the corresponding PCIe
interfaces in the Device Tree.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-db.dts | 33 +
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index e83505e..54cc5bb 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -121,5 +121,38 @@
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;
+ };
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 16/19] arm: mvebu: PCIe Device Tree informations for Armada 370 Mirabox
The Globalscale Mirabox platform uses one PCIe interface for an
available mini-PCIe slot, and the other PCIe interface for an internal
USB 3.0 controller. We add the necessary Device Tree informations to
enable those two interfaces.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-370-mirabox.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index dd0c57d..5549de6 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -70,5 +70,21 @@
usb@d0051000 {
status = okay;
};
+
+ 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;
+ };
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 17/19] arm: mvebu: PCIe Device Tree informations for Armada 370 DB
The Marvell evaluation board (DB) for the Armada 370 SoC has 2
physical full-size PCIe slots, so we enable the corresponding PCIe
interfaces in the Device Tree.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-370-db.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index e34b280..6403acd 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -94,5 +94,22 @@
spi-max-frequency = 5000;
};
};
+
+ pcie-controller {
+ status = okay;
+ /*
+* The two PCIe units are accessible through
+* both standard PCIe slots and mini-PCIe
+* slots on the board.
+*/
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+ pcie@2,0 {
+ /* Port 1, Lane 0 */
+ status = okay;
+ };
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 18/19] arm: mvebu: PCIe Device Tree informations for Armada XP GP
The Marvell Armada XP GP board has 3 physical full-size PCIe slots, so
we enable the corresponding PCIe interfaces in the Device Tree.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
arch/arm/boot/dts/armada-xp-gp.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts
b/arch/arm/boot/dts/armada-xp-gp.dts
index 1c8afe2..e2bf6b4 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -109,5 +109,26 @@
spi-max-frequency = 10800;
};
};
+
+ pcie-controller {
+ status = okay;
+
+ /*
+* The 3 slots are physically present as
+* standard PCIe slots on the board.
+*/
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = okay;
+ };
+ pcie@9,0 {
+ /* Port 2, Lane 0 */
+ status = okay;
+ };
+ pcie@10,0 {
+ /* Port 3, Lane 0 */
+ status = okay;
+ };
+ };
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCHv8 19/19] arm: mvebu: update defconfig with PCI and USB support
Now that we have the necessary drivers and Device Tree informations to support PCIe on Armada 370 and Armada XP, enable the CONFIG_PCI option. Also, since the Armada 370 Mirabox has a built-in USB XHCI controller connected on the PCIe bus, enable the corresponding options as well. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com --- arch/arm/configs/mvebu_defconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig index 2ec8119..071a5b1 100644 --- a/arch/arm/configs/mvebu_defconfig +++ b/arch/arm/configs/mvebu_defconfig @@ -13,6 +13,8 @@ CONFIG_MACH_ARMADA_370=y CONFIG_MACH_ARMADA_XP=y # CONFIG_CACHE_L2X0 is not set # CONFIG_SWP_EMULATE is not set +CONFIG_PCI=y +CONFIG_PCI_MVEBU=y CONFIG_SMP=y CONFIG_AEABI=y CONFIG_HIGHMEM=y @@ -53,6 +55,7 @@ CONFIG_USB_SUPPORT=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_ROOT_HUB_TT=y +CONFIG_USB_XHCI_HCD=y CONFIG_MMC=y CONFIG_MMC_MVSDIO=y CONFIG_NEW_LEDS=y -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv8 10/19] pci: PCIe driver for Marvell Armada 370/XP systems
On Tue, Apr 9, 2013 at 3:06 PM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:
This driver implements the support for the PCIe interfaces on the
Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
cover earlier families of Marvell SoCs, such as Dove, Orion and
Kirkwood.
The driver implements the hw_pci operations needed by the core ARM PCI
code to setup PCI devices and get their corresponding IRQs, and the
pci_ops operations that are used by the PCI core to read/write the
configuration space of PCI devices.
Since the PCIe interfaces of Marvell SoCs are completely separate and
not linked together in a bus, this driver sets up an emulated PCI host
bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
interface.
In addition, this driver enumerates the different PCIe slots, and for
those having a device plugged in, it sets up the necessary address
decoding windows, using the new armada_370_xp_alloc_pcie_window()
function from mach-mvebu/addr-map.c.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Acked-by: Bjorn Helgaas bhelg...@google.com
This and 06/19 look good to me.
---
.../devicetree/bindings/pci/mvebu-pci.txt | 220 +
drivers/pci/host/Kconfig |4 +
drivers/pci/host/Makefile |2 +-
drivers/pci/host/pci-mvebu.c | 879
4 files changed, 1104 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt
create mode 100644 drivers/pci/host/pci-mvebu.c
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
new file mode 100644
index 000..eb69d92
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -0,0 +1,220 @@
+* Marvell EBU PCIe interfaces
+
+Mandatory properties:
+- compatible: one of the following values:
+marvell,armada-370-pcie
+marvell,armada-xp-pcie
+- #address-cells, set to 3
+- #size-cells, set to 2
+- #interrupt-cells, set to 1
+- bus-range: PCI bus numbers covered
+- device_type, set to pci
+- ranges: ranges for the PCI memory and I/O regions, as well as the
+ MMIO registers to control the PCIe interfaces.
+
+In addition, the Device Tree node must have sub-nodes describing each
+PCIe interface, having the following mandatory properties:
+- reg: used only for interrupt mapping, so only the first four bytes
+ are used to refer to the correct bus number and device number.
+- assigned-addresses: reference to the MMIO registers used to control
+ this PCIe interface.
+- clocks: the clock associated to this PCIe interface
+- marvell,pcie-port: the physical PCIe port number
+- status: either disabled or okay
+- device_type, set to pci
+- #address-cells, set to 3
+- #size-cells, set to 2
+- #interrupt-cells, set to 1
+- ranges, empty property.
+- interrupt-map-mask and interrupt-map, standard PCI properties to
+ define the mapping of the PCIe interface to interrupt numbers.
+
+and the following optional properties:
+- marvell,pcie-lane: the physical PCIe lane number, for ports having
+ multiple lanes. If this property is not found, we assume that the
+ value is 0.
+
+Example:
+
+pcie-controller {
+ compatible = marvell,armada-xp-pcie;
+ status = disabled;
+ device_type = pci;
+
+ #address-cells = 3;
+ #size-cells = 2;
+
+ bus-range = 0x00 0xff;
+
+ ranges = 0x8200 0 0xd004 0xd004 0 0x2000 /* Port
0.0 registers */
+ 0x8200 0 0xd0042000 0xd0042000 0 0x2000 /* Port
2.0 registers */
+ 0x8200 0 0xd0044000 0xd0044000 0 0x2000 /* Port
0.1 registers */
+ 0x8200 0 0xd0048000 0xd0048000 0 0x2000 /* Port
0.2 registers */
+ 0x8200 0 0xd004c000 0xd004c000 0 0x2000 /* Port
0.3 registers */
+ 0x8200 0 0xd008 0xd008 0 0x2000 /* Port
1.0 registers */
+ 0x8200 0 0xd0082000 0xd0082000 0 0x2000 /* Port
3.0 registers */
+ 0x8200 0 0xd0084000 0xd0084000 0 0x2000 /* Port
1.1 registers */
+ 0x8200 0 0xd0088000 0xd0088000 0 0x2000 /* Port
1.2 registers */
+ 0x8200 0 0xd008c000 0xd008c000 0 0x2000 /* Port
1.3 registers */
+ 0x8200 0 0xe000 0xe000 0 0x0800 /*
non-prefetchable memory */
+ 0x8100 0 0 0xe800 0 0x0010; /*
downstream I/O */
+
+ pcie@1,0 {
+ device_type = pci;
+ assigned-addresses = 0x82000800 0 0xd004 0 0x2000;
+ reg = 0x0800 0 0 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ #interrupt-cells = 1;
+
Re: [PATCHv8 10/19] pci: PCIe driver for Marvell Armada 370/XP systems
Dear Bjorn Helgaas, On Tue, 9 Apr 2013 15:12:58 -0600, Bjorn Helgaas wrote: On Tue, Apr 9, 2013 at 3:06 PM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: This driver implements the support for the PCIe interfaces on the Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to cover earlier families of Marvell SoCs, such as Dove, Orion and Kirkwood. The driver implements the hw_pci operations needed by the core ARM PCI code to setup PCI devices and get their corresponding IRQs, and the pci_ops operations that are used by the PCI core to read/write the configuration space of PCI devices. Since the PCIe interfaces of Marvell SoCs are completely separate and not linked together in a bus, this driver sets up an emulated PCI host bridge, with one PCI-to-PCI bridge as child for each hardware PCIe interface. In addition, this driver enumerates the different PCIe slots, and for those having a device plugged in, it sets up the necessary address decoding windows, using the new armada_370_xp_alloc_pcie_window() function from mach-mvebu/addr-map.c. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Acked-by: Bjorn Helgaas bhelg...@google.com This and 06/19 look good to me. Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v5 1/3] i2c: mux: Add i2c-arb-gpio-challenge 'mux' driver
The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
where masters need to claim the bus with a GPIO before they can start
a transcation. This should generally only be used when standard I2C
multimaster isn't appropriate for some reason (errata/bugs).
This driver is based on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree. The current incarnation as a
mux driver is as suggested by Grant Likely. See
https://patchwork.kernel.org/patch/1877311/ for some history.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Stephen Warren swar...@nvidia.com
---
(Sorry if you got v5 more than once--apparently the CC list has grown
too long and my mail was rejected; resending with a shorter header)
Changes in v5:
- Renamed as per Wolfram Sang.
- Avoid references to AP and EC.
- Bindings are now generic and could support N other masters; code
still only supports one other master.
- Replaced all instances of WARN_ON with error messages.
- Left Stephen's Reviewed-by from v4 since changes aren't huge, but
please yell if you want it removed or don't like something about the
new code; removed Naveen's Tested-by for now.
Changes in v4: None
Changes in v3:
- Handle of_find_i2c_adapter_by_node() failure more properly by
changing init order.
- Don't warn on -EPROBE_DEFER from calls that could return it.
- Move to module_platform_driver(). As we pull in parts of the system
that rely on devices under this i2c bus we'll need to make sure they
can handle the fact that they'll be initted later now.
Changes in v2:
- Renamed to i2c-arb-gpio-challenge.
- Documented microsecond properties as optional; removed
bus-arbitration prefix since it was just extra wordy.
- Split GPIOs into two properties to make it cleaner.
- Capitalized I2C in freeform text.
- Get 'active low' from device tree.
.../bindings/i2c/i2c-arb-gpio-challenge.txt| 80 +++
drivers/i2c/muxes/Kconfig | 11 +
drivers/i2c/muxes/Makefile | 2 +
drivers/i2c/muxes/i2c-arb-gpio-challenge.c | 252 +
4 files changed, 345 insertions(+)
create mode 100644
Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
create mode 100644 drivers/i2c/muxes/i2c-arb-gpio-challenge.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
new file mode 100644
index 000..726e099
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
@@ -0,0 +1,80 @@
+GPIO-based I2C Arbitration
+==
+This uses GPIO lines to arbitrate who is the master of an I2C bus in a
+multimaster situation.
+
+In many cases using GPIOs to arbitrate is not needed and a design can use
+the standard I2C multi-master rules. Using GPIOs is generally useful in
+the case where there is a device on the bus that has errata and/or bugs
+that makes standard multimaster mode not feasible.
+
+
+Algorithm:
+
+All masters on the bus have a 'bus claim' line which is an output that the
+others can see. These are all active low with pull-ups enabled. We'll
+describe these lines as:
+
+- OUR_CLAIM: output from us signaling to other hosts that we want the bus
+- THEIR_CLAIMS: output from others signaling that they want the bus
+
+The basic algorithm is to assert your line when you want the bus, then make
+sure that the other side doesn't want it also. A detailed explanation is best
+done with an example.
+
+Let's say we want to claim the bus. We:
+1. Assert OUR_CLAIM.
+2. Waits a little bit for the other sides to notice (slew time, say 10
+ microseconds).
+3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we
are
+ done.
+4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
+5. If not, back off, release the claim and wait for a few more milliseconds.
+6. Go back to 1 (until retry time has expired).
+
+
+Required properties:
+- compatible: i2c-arb-gpio-challenge
+- our-claim-gpio: The GPIO that we use to claim the bus.
+- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
+ Note that some implementations may only support a single other master.
+- Standard I2C mux properties. See mux.txt in this directory.
+- Single I2C child bus node at reg 0. See mux.txt in this directory.
+
+Optional properties:
+- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
+- wait-retry-us: we'll attempt another claim after this many microseconds.
+Default is 3000 us.
+- wait-free-us: we'll give up after this many microseconds. Default is 5
us.
+
+
+Example:
+ i2c@12CA {
+ compatible = acme,some-i2c-device;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
+
+
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 15:49-20130409, Nishanth Menon wrote:
On 10:43-20130409, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130409 09:54]:
* Roger Quadros rog...@ti.com [130409 03:00]:
On 04/05/2013 06:58 PM, Tony Lindgren wrote:
Can't you just use the clock name there to get it?
In device tree we don't pass around clock names. You can either get
a phandle or an index to the clock.
e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
Yes I understand that. But the driver/clock/omap driver can just
remap the DT device initially so the board specific clock is
found from the clock alias table. Basically initially a passthrough
driver that can be enhanced to parse DT clock bindings and load
data from /lib/firmware.
Actually probably the driver/clock/omap can even do even less
initially. There probably even no need to remap clocks there.
As long as the DT clock driver understands that a board specific
auxclk is specified in the DT it can just call clk_add_alias() so
the driver will get the right auxclk from cclock44xx_data.c.
Then other features can be added later on like to allocate a
clock entirely based on the binding etc.
I did try to have an implementation for cpufreq using clock nodes.
unfortunately, device tree wont let me have arguments of strings :(
So, I am unable to do clock = clk mpu_dpll;
instead, I am forced to do clock = clk 249;
Here is an attempt on beagleXM - adds every clock node to the list.
Tons of un-necessary prints added to give an idea - see log:
http://pastebin.com/F9A2zSTr
Would an cleaned up version be good enough as a step #1 of transition?
Approach #2:
Here is yet another revision - here I am trying to avoid the risk of
folks messing up indexing. for example: using an older DTB with newer
kernel, clocks being inserted into existing list etc. to prevent these,
we add an DT_ID for omap clock nodes, and use it to uniquely identify
the clock node. We try to minimize(not avoidable with integer indexing)
mistakes during development/productization.
From 2b576affdc6f6bf0b51ebf9b85ef4319357a7994 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 26 Mar 2013 10:23:27 +
Subject: [RFC PATCH V2] OMAP: add devicetree support for clock nodes.(rev 2)
Dummy patch based on Roger's original idea
this time have lesser possibiltiy of screwing up indices. instead
use a specific integer ID to uniquely (TI SoC wide) identify an clock.
on the flip side, we do not all make clock nodes to be accesible from DT
clock indexing.
Nyet-Signed-off-by: Nishanth Menon n...@ti.com
---
.../devicetree/bindings/clock/ti,clock.txt | 48 +++
arch/arm/boot/dts/omap3.dtsi |5 ++
arch/arm/boot/dts/omap34xx.dtsi|2 +
arch/arm/boot/dts/omap4.dtsi |5 ++
arch/arm/boot/dts/omap443x.dtsi|2 +
arch/arm/mach-omap2/cclock3xxx_data.c |5 +-
arch/arm/mach-omap2/cclock44xx_data.c |5 +-
arch/arm/mach-omap2/clock.h| 12 +++
arch/arm/mach-omap2/pm.c | 11 ++-
drivers/clk/Kconfig|6 ++
drivers/clk/Makefile |2 +
drivers/clk/ti.c | 85
include/linux/clk/ti.h | 30 +++
13 files changed, 211 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti,clock.txt
create mode 100644 drivers/clk/ti.c
create mode 100644 include/linux/clk/ti.h
diff --git a/Documentation/devicetree/bindings/clock/ti,clock.txt
b/Documentation/devicetree/bindings/clock/ti,clock.txt
new file mode 100644
index 000..53c947c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,clock.txt
@@ -0,0 +1,48 @@
+* Clock bindings for Texas Instruments clocks
+
+Required properties:
+- compatible: Should be ti,clock
+- #clock-cells: Should be 1
+
+The clock consumer should specify the desired clock by having the clock
+ID in its clocks phandle cell. The following is a list of ID reservations
+across TI SoCs
+
+ Clock ID
+ --
+ cpu clock 1
+
+The definition is used by SoC clock data using CLKDT() macro
+(example of OMAP2+).
+
+Example Steps:
+/* step 1: definiting an SoC nodes compatible with ti clocks -skip if already
done */
+clks: clocks {
+ compatible = ti,clock;
+ #clock-cells = 1;
+};
+
+/* step 2: Modify the bindings documentation to reserve an ID */
+ auxclk0_ck 2
+ auxclk1_ck 3
+ auxclk2_ck 4
+ auxclk3_ck 5
+ auxclk4_ck 6
+ auxclk5_ck 7
+etc. use an unique number not conflicting with previous reservations.
+WARNING: DONOT insert values - this breaks backward compatibility.
+/* Step 3: replace in clock data file
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
* Nishanth Menon n...@ti.com [130409 13:53]:
I did try to have an implementation for cpufreq using clock nodes.
unfortunately, device tree wont let me have arguments of strings :(
So, I am unable to do clock = clk mpu_dpll;
instead, I am forced to do clock = clk 249;
It seems that you should have a separate clock defines for each
clock instead. That way we can later on populate that with
the clock specific data.
Here is an attempt on beagleXM - adds every clock node to the list.
Tons of un-necessary prints added to give an idea - see log:
http://pastebin.com/F9A2zSTr
Would an cleaned up version be good enough as a step #1 of transition?
Well I would make it even simpler initially. Just a standard .dts
clock defined that gets parsed by drivers/clock/ driver that just
calls clk_add_alias(). Then the consumer driver can just do clk_get()
and and the right clock is found, see below.
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -73,6 +73,11 @@
ti,hwmods = counter_32k;
};
+ clks: clocks {
+ compatible = ti,clock;
+ #clock-cells = 1;
+ };
+
intc: interrupt-controller@4820 {
compatible = ti,omap2-intc;
interrupt-controller;
There should be a separate entry for each clock defined,
like auxclk1 in the USB case assuming the clock being used
is aux clock #1. I doubt that we want to map all the auxclks
as a single clock as they are separate clocks AFAIK.
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -23,6 +23,8 @@
60 135
;
clock-latency = 30; /* From legacy driver */
+ clocks = clks 249; /* index to cpufreq_ck */
+ clock-names = cpu;
};
};
};
Then in the consumer driver you would just have:
clocks = auxclk1 0;
for the USB case, then something else for the cpufreq driver.
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -22,6 +22,7 @@
#include linux/clk-private.h
#include linux/list.h
#include linux/io.h
+#include linux/clk/ti.h
#include soc.h
#include iomap.h
@@ -3574,7 +3575,7 @@ int __init omap3xxx_clk_init(void)
for (c = omap3xxx_clks; c omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
c++)
if (c-cpu cpu_clkflg) {
- clkdev_add(c-lk);
+ ti_clk_node_add(c-lk);
if (!__clk_init(NULL, c-lk.clk))
omap2_init_clk_hw_omap_clocks(c-lk.clk);
}
AFAIK no need to tinkering with the clock_data.c files.
--- /dev/null
+++ b/drivers/clk/ti.c
@@ -0,0 +1,100 @@
+/*
+ * TI Clock node provider
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include linux/kernel.h
+#include linux/list.h
+#include linux/clk-private.h
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/of.h
+#include linux/clk/ti.h
Then this can be just a minimal DT device driver that initially just
calls clk_add_alias() so the right clock is found when the driver
does clk_get(). Probably should be drivers/clock/omap/clk.c.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] irqchip: renesas-intc-irqpin: DT binding for sense bitfield width
Hi Guennadi, On Mon, Apr 8, 2013 at 5:08 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Most Renesas irqpin controllers have 4-bit sense fields, however, some have different widths. This patch adds a DT binding to optionally specify such non-standard values. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com --- v3: move the code to a common location, where device configuration parameters are retrieved Thanks for rearranging the code, this looks good to me. Acked-by: Magnus Damm d...@opensource.se To be clear, I prefer your approach over a per-SoC compatible string. In general I think a per-SoC compatible string is nice in theory, but I don't think it is correct to use it to describe a change in a IP block that just happens to included in the SoC. Instead the version of the IP block shall be used with the compatible value. In some cases it may not be easy to retrieve such a version. The per-SoC compatible string may look good but they come with at least two drawbacks. Either 1) the driver has to be updated for each new SoC even though the device IP the driver is handling hasn't changed which leads to 1.1) more need for pointless per-SoC compatible string patches to be merged and tracked and back ported and 1.2) less chance of running a standard distro lacking per-SoC compatible string but has actual code for support or 2) to ship soon the per-SoC DT will use SoC compatible strings matching other SoC names which works but is even more confusing. For the INTC irqpin case I believe this approach with a single property is the best. Thanks, / magnus ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/7] i.MX53 IPU + TVE patches
On Tue, Apr 09, 2013 at 09:44:46AM +0200, Philipp Zabel wrote: Hi Greg, Am Montag, den 08.04.2013, 10:40 -0700 schrieb Greg Kroah-Hartman: On Mon, Apr 08, 2013 at 06:04:31PM +0200, Philipp Zabel wrote: Hi, the following patches allow to use the integrated Television Encoder (TVEv2) on the i.MX53 SoC as VGA output encoder for the IPU. This is useful for the Freescale i.MX53-QSB and TQ MBa53 boards, which have VGA and DVI-I connectors, respectively. regards Philipp --- drivers/staging/imx-drm/Kconfig | 7 + drivers/staging/imx-drm/Makefile| 1 + drivers/staging/imx-drm/imx-drm-core.c | 15 +- drivers/staging/imx-drm/imx-drm.h | 14 +- drivers/staging/imx-drm/imx-tve.c | 755 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 3 + drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 55 +- drivers/staging/imx-drm/ipu-v3/ipu-di.c | 100 +++- drivers/staging/imx-drm/ipuv3-crtc.c| 11 +- 9 files changed, 932 insertions(+), 29 deletions(-) That's a lot of new features being added here, yet no work seems to be happening to move this out of the staging tree. What is left to do here, and why isn't that being worked on first, before stuff like this? the IPU code could still use a bit of testing, and I hope adding features like VGA output on common development boards will increase the amount of scrutiny this code will get. I expect the structure of the IPU drivers to change when the common display framework gets introduced at last, also requiring changes to the device tree bindings, and I'm a bit reluctant to push for mainline proper while the bindings are still not clear. Ok, thanks for the information. Is the TODO file still correct with these changes? If not, care to send a patch to update it as well? thanks, greg k-h ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] irqchip: renesas-intc-irqpin: DT binding for sense bitfield width
On Wed, Apr 10, 2013 at 07:23:06AM +0900, Magnus Damm wrote: Hi Guennadi, On Mon, Apr 8, 2013 at 5:08 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Most Renesas irqpin controllers have 4-bit sense fields, however, some have different widths. This patch adds a DT binding to optionally specify such non-standard values. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com --- v3: move the code to a common location, where device configuration parameters are retrieved Thanks for rearranging the code, this looks good to me. Acked-by: Magnus Damm d...@opensource.se Thanks, queued-up in the renesas-intc-irqpin branch. To be clear, I prefer your approach over a per-SoC compatible string. In general I think a per-SoC compatible string is nice in theory, but I don't think it is correct to use it to describe a change in a IP block that just happens to included in the SoC. Instead the version of the IP block shall be used with the compatible value. In some cases it may not be easy to retrieve such a version. The per-SoC compatible string may look good but they come with at least two drawbacks. Either 1) the driver has to be updated for each new SoC even though the device IP the driver is handling hasn't changed which leads to 1.1) more need for pointless per-SoC compatible string patches to be merged and tracked and back ported and 1.2) less chance of running a standard distro lacking per-SoC compatible string but has actual code for support or 2) to ship soon the per-SoC DT will use SoC compatible strings matching other SoC names which works but is even more confusing. For the INTC irqpin case I believe this approach with a single property is the best. Thanks, / magnus ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH/RFC 0/2] ARM: shmobile: DT irqpin for r8a7779 and marzen-reference
On Fri, Apr 05, 2013 at 11:13:39AM +0900, Simon Horman wrote: On Fri, Apr 05, 2013 at 10:44:29AM +0900, Simon Horman wrote: On Thu, Apr 04, 2013 at 11:47:05PM +0200, Guennadi Liakhovetski wrote: Hi Simon On Thu, 4 Apr 2013, Simon Horman wrote: On Wed, Apr 03, 2013 at 11:18:57AM +0200, Guennadi Liakhovetski wrote: Hi This 2 patches add DT irqpin support on marzen-reference. Only compile-tested due to the lack of hardware. The patches can go independently via their respective trees. irqpin on marzen will not work if patch 2 is applied before patch 1, but as long as there are no devices, using irqpin interrupts, no breakage will be caused. I have applied both patches and the dependency I mention below. I have also applied the small patch, inlined below, to hook-up the LAN controller. Unfortunately it doesn't seem to be receiving any interrupts. Perhaps I am missing something? Are you sure 28 is the correct number in the irqpin IRQ space? Seems strange to me. Should be 1 perhaps (counting from 0), or 2 - not sure how that mapping would look like. Thanks! 0 seems to be the lucky number, I have SMSC (and NFS root) working on marzen-reference. s/0/1/ After all that it seems that I miss-tested the code somehow. It turns out that 2 is the lucky number. I have posted ARM: shmobile: marzen-reference: use irqpin for lan Guennadi Liakhovetski (2): irqchip: renesas-intc-irqpin: DT binding for sense bitfield width The above patch depends on [1/3] ARM: shmobile: irqpin: fix handling of spurious interrupts in DT case, right? Not functionally. Spurious interrupts occur on sh73a0, the sense bitfield is needed for r8a7779. But the latter won't apply without the former, that's right. Thanks, could you reposts this series rebase so that it doesn't require [1/3] ARM: shmobile: irqpin: fix handling of spurious interrupts in DT case to apply cleanly. Feel free to break the creation of Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt into a separate patch. Please add ARM: shmobile: marzen-reference: use irqpin for lan to the end of the series with an Ack if you have no objections to it. Has there been any progress in your discussions with Magnus about what to do about that patch? No, not yet. Thanks, understood. And thanks doubly for this series. It is very nice to have bouth irqpin and ethernet working on marzen-reference. -- To unsubscribe from this list: send the line unsubscribe linux-sh in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-sh in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH/RFC 2/2] ARM: shmobile: marzen-reference: add irqpin support in DT
On Wed, Apr 03, 2013 at 11:19:07AM +0200, Guennadi Liakhovetski wrote: Add an irqpin interrupt controller DT node on marzen-reference. Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com Thanks, queued up in the boards-marzen branch. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH/RFC 0/2] ARM: shmobile: DT irqpin for r8a7779 and marzen-reference
On Wed, Apr 10, 2013 at 10:08:18AM +0900, Simon Horman wrote: On Fri, Apr 05, 2013 at 11:13:39AM +0900, Simon Horman wrote: On Fri, Apr 05, 2013 at 10:44:29AM +0900, Simon Horman wrote: On Thu, Apr 04, 2013 at 11:47:05PM +0200, Guennadi Liakhovetski wrote: Hi Simon On Thu, 4 Apr 2013, Simon Horman wrote: On Wed, Apr 03, 2013 at 11:18:57AM +0200, Guennadi Liakhovetski wrote: Hi This 2 patches add DT irqpin support on marzen-reference. Only compile-tested due to the lack of hardware. The patches can go independently via their respective trees. irqpin on marzen will not work if patch 2 is applied before patch 1, but as long as there are no devices, using irqpin interrupts, no breakage will be caused. I have applied both patches and the dependency I mention below. I have also applied the small patch, inlined below, to hook-up the LAN controller. Unfortunately it doesn't seem to be receiving any interrupts. Perhaps I am missing something? Are you sure 28 is the correct number in the irqpin IRQ space? Seems strange to me. Should be 1 perhaps (counting from 0), or 2 - not sure how that mapping would look like. Thanks! 0 seems to be the lucky number, I have SMSC (and NFS root) working on marzen-reference. s/0/1/ After all that it seems that I miss-tested the code somehow. It turns out that 2 is the lucky number. My, what a mess I have made. It seems that I miss-tested again (using non-reference boot instead of reference boot). Unfortunately I am not able to get the NIC running after all. Booting Linux on physical CPU 0x0 Linux version 3.9.0-rc2-4-gb1480a8 (ho...@ayumi.isobedori.kobe.vergenet.net) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #1642 SMP Wed Apr 10 10:28:59 JST 2013 CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: marzen, model: marzen debug: ignoring loglevel setting. Memory policy: ECC disabled, Data cache writealloc On node 0 totalpages: 262144 free_area_init_node: node 0, pgdat c0534c00, node_mem_map c082b000 Normal zone: 1520 pages used for memmap Normal zone: 0 pages reserved Normal zone: 194560 pages, LIFO batch:31 HighMem zone: 528 pages used for memmap HighMem zone: 67584 pages, LIFO batch:15 PERCPU: Embedded 5 pages/cpu @c1033000 s6720 r0 d13760 u32768 pcpu-alloc: s6720 r0 d13760 u32768 alloc=8*4096 pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260624 Kernel command line: console=ttySC2,115200 earlyprintk=sh-sci.2,115200 ignore_loglevel root=/dev/nfs ip=on PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) __ex_table already sorted, skipping sort Memory: 1024MB = 1024MB total Memory: 1033972k/1033972k available, 14604k reserved, 270336K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) vmalloc : 0xf000 - 0xff00 ( 240 MB) lowmem : 0xc000 - 0xef80 ( 760 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) .text : 0xc0008000 - 0xc037fc60 (3552 kB) .init : 0xc038 - 0xc0511a40 (1607 kB) .data : 0xc0512000 - 0xc05357c0 ( 142 kB) .bss : 0xc05357c0 - 0xc0560274 ( 171 kB) Hierarchical RCU implementation. NR_IRQS:16 nr_irqs:16 16 sched_clock: 32 bits at 1kHz, resolution 976562ns, wraps every 4194303999ms Calibrating delay loop (skipped) preset value.. 1000.00 BogoMIPS (lpj=488000) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok Setting up static identity map for 0xc02db328 - 0xc02db380 CPU1: Booted secondary processor CPU2: Booted secondary processor CPU3: Booted secondary processor Brought up 4 CPUs SMP: Total of 4 processors activated (4000.00 BogoMIPS). CPU: All CPU(s) started in SVC mode. devtmpfs: initialized pinctrl core: initialized pinctrl subsystem NET: Registered protocol family 16 DMA: preallocated 256 KiB pool for atomic coherent allocations sh-pfc pfc-r8a7779: r8a7779_pfc support registered renesas_intc_irqpin fe78001c.irqpin: driving 4 irqs No ATAGs? bio: create slab bio-0 at 0 SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb sh_tmu sh_tmu.0: Runtime PM disabled, clock forced on. sh_tmu sh_tmu.0: used for clock events sh_tmu sh_tmu.0: used for periodic clock events sh_tmu sh_tmu.1: Runtime PM disabled, clock forced on. sh_tmu sh_tmu.1: used as clock source Switching to clocksource sh_tmu.1 Clockevents: could not switch to one-shot mode: Clockevents: could not
[PATCH v2] of/base: release the node correctly in of_parse_phandle_with_args()
From: Tang Yuantian yuantian.t...@freescale.com
Call of_node_put() only when the out_args is NULL on success,
or the node's reference count will not be correct because the caller
will call of_node_put() again.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
v2:
- modified the title and description. the 1st patch title is:
of: remove the unnecessary of_node_put for
of_parse_phandle_with_args()
the 1st patch is not good enough.
drivers/of/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 321d3ef..ee94f64 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1158,6 +1158,7 @@ static int __of_parse_phandle_with_args(const struct
device_node *np,
if (!phandle)
goto err;
+ /* Found it! return success */
if (out_args) {
int i;
if (WARN_ON(count MAX_PHANDLE_ARGS))
@@ -1166,11 +1167,10 @@ static int __of_parse_phandle_with_args(const struct
device_node *np,
out_args-args_count = count;
for (i = 0; i count; i++)
out_args-args[i] =
be32_to_cpup(list++);
+ } else if (node) {
+ of_node_put(node);
}
- /* Found it! return success */
- if (node)
- of_node_put(node);
return 0;
}
--
1.8.0
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
