Re: [PATCH 1/2] ARM: sunxi: gpio: Add Allwinner SoCs GPIO drivers
Hi Linus,
On 10/01/2013 12:06, Linus Walleij wrote:
On Fri, Jan 4, 2013 at 5:45 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
+static int __devinit
+sunxi_pinctrl_register_gpio_ranges(struct sunxi_pinctrl *pctl)
+{
+ int id = 0, base = 0, npins = 1, i, prev_pin = -1;
+ struct pinctrl_gpio_range *range;
+
+ for (i = 0; i pctl-desc-npins; i++) {
+ const struct sunxi_desc_pin *pin = pctl-desc-pins + i;
+ unsigned pin_num = pin-pin.number;
+
+ if (prev_pin 0) {
+ prev_pin = pin_num;
+ base = pin_num;
+ } else if (prev_pin + 1 != pin_num) {
+ range = devm_kzalloc(pctl-dev,
+ sizeof(*range),
+ GFP_KERNEL);
+ if (!range)
+ return -ENOMEM;
+
+ range-name = sunxi;
+ range-id = id;
+ range-base = base;
+ range-pin_base = base;
+ range-npins = npins;
+
+ pinctrl_add_gpio_range(pctl-pctl_dev, range);
+
+ id++;
+ npins = 1;
+ prev_pin = pin_num;
+ base = prev_pin;
+ } else {
+ prev_pin++;
+ npins++;
+ }
+ }
+
+ range = devm_kzalloc(pctl-dev, sizeof(*range),
+ GFP_KERNEL);
+ if (!range)
+ return -ENOMEM;
+
+ range-name = sunxi;
+ range-id = id;
+ range-base = base;
+ range-pin_base = base;
+ range-npins = npins;
+
+ pinctrl_add_gpio_range(pctl-pctl_dev, range);
+
+ return 0;
+}
Really hairy way to add ranges right?
Yes... I didn't find any best way to do so. It was either that or
duplicate the already existing informations we had about the pins ranges
into a ranges array, which is pretty error-prone.
I guess I could add some comments though.
Registering ranges from the pinctrl side is deprecated and discouraged.
Instead register the ranges from the GPIO driver.
Use gpiochip_add_pin_range() from the GPIO driver.
An example is provided in
drivers/pinctrl/pinctrl-coh901.c
Ok, will do. But we need to find a way to share the pins arrays between
the pinctrl and gpio drivers then.
Maybe add a pinctrl-sunxi-pins.h file? or merge the pinctrl and gpio
drivers?
I'm kind of reluctant to merging the drivers into one single messy file,
but if that's the way to go, fine.
After you have done this, you can probably get rid of this as well:
+static int __init sunxi_gpio_init(void)
+{
+ return platform_driver_register(sunxi_gpio_driver);
+}
+postcore_initcall(sunxi_gpio_init);
This will become a simple module_init() if you are handling
deferred probe correctly.
Ok. Thanks for your review!
Maxime
--
Maxime Ripard, 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: [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
On Fri, Jan 11, 2013 at 04:45:16PM +0100, Thierry Reding wrote:
On Fri, Jan 11, 2013 at 03:36:14PM +, Arnd Bergmann wrote:
On Friday 11 January 2013, Thierry Reding wrote:
Right, it'll need #ifdefs around the arch_{setup,teardown}_msi_irq(). Or
select PCI_MSI unconditionally. Once this is merged I was going to post
a patch that enables PCI_MSI in tegra_defconfig anyway. But it might be
better to keep it optional anyway since the remainder of the code copes
with it properly.
Actually, we need something better than that. You cannot define
arch_setup_msi_irq in a tegra specific pci host driver, because that
will seriously mess up other platforms in multiplatform configurations
by giving a link error when they also define this function, or with a
run-time error when they don't support it.
I think what we should do here is fix it the right way by adding
a pci host specific callback rather than an architecture specific
callback in drivers/pci/msi.c. There is already a default version
of arch_setup_msi_irqs (with s), and we can probably do the
same for arch_setup_msi_irq (without s) to fall back to the
arch version for most architectures.
Most architectures (at least powerpc, sparc, ia64 and x86) already
multiplex the msi handlers internally, but ARM does not because
there is only one implementation (iop33x) at the moment.
We can add a generix multiplex and then move architectures over to
use it.
I already hinted at that in one of the other subthreads. Having such a
multiplex would also allow the driver to be built as a module. I had
already thought about this when I was working on an earlier version of
these patches. Basically these would be two ops attached to the host
bridge, and the generic arch_setup_msi_irq() could then look that up
given the struct pci_dev that is passed to it and call this new per-
host bridge .setup_msi_irq().
struct pci_ops looks like a good place to put these. They'll be
available from each struct pci_bus, so should be easy to call from
arch_setup_msi_irq().
Any objections?
Thierry
pgpvzISuDJ6VJ.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: PMU node location
On 01/10/2013 07:47 AM, Michal Simek wrote: Hi Rob, Mark, Grant and others, I want to check with you the location of ARM pmu node I see that 1) highbank and dbx5x0 have it in soc node 2) vexpress and tegra have no main bus and pmu is in root like all others devices. (Any reason no to have main bus? Does it mean that there is no bus or that all devices are accessible?) That seems really wrong in general. Any memory mapped device is on a bus of some kind. I'm not sure the reasoning. Perhaps Stephen can explain. 3) omap2/omap3 have added pmu node to root node(mailing list) 4) Just for completeness no platform has it in the bus. That's why I have obvious question what it is proper location for pmu node? Obviously, highbank is the true and correct way. ;) The pmu is part of the cpu, so it could be part of /cpus. That may cause problems having non-cpu nodes and it would not get probed (although technically that is a Linux problem and should not influence the DT). Since it is not on a bus, then putting it at the top level probably makes more sense than on a bus. Rob Thanks, Michal ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V7] kbuild: create a rule to run the pre-processor on *.dts files
On Wed, Jan 2, 2013 at 10:43 AM, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com Create cmd_dtc_cpp to run the C pre-processor on *.dts file before passing them to dtc for final compilation. This allows the use of #define and #include within the .dts file. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Simon Glass s...@chromium.org --- Grant, back in mid-November, you said you'd make a decision on this in the next couple of days, but I think this got overlooked. v7: Build *.dtb from *.dts not src/*.dts. v6: No change. v5: * Update Documentation/kbuild for the new command and rule. v4: * Use -x assembler-with-cpp so pre-defined macros are set up so that #included header files know to only use cpp syntax, not C syntax. * Define __DTS__ for similar reasons. * use $(CPP) not $(CC) -E, and use $(cpp_flags). * Save the pre-processed results so they can be easily inspected when debugging build issues. * The use of -x assembler-with-cpp causes cpp to recognize directives in column 1 only. Hence, there's no need to escape property names that begin with #. Hence, there's no need for separate skeleton.dtsi and skeleton.dtsip. Maintain a separate file extension and build rule so that CPP-usage is opt-in. In particular, when using CPP, #include must be used rather than /include/ so that dependencies work. v3: Pass -x c not -xc to cpp. v2: Place make %.dtb: %.dtsp rule into Makefile.lib. --- Documentation/kbuild/makefiles.txt | 23 +++ scripts/Makefile.lib |9 + 2 files changed, 32 insertions(+) diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 14c3f4f..5198b74 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -1186,6 +1186,29 @@ When kbuild executes, the following steps are followed (roughly): clean-files += *.dtb DTC_FLAGS ?= -p 1024 +dtc_cpp + This is just like dtc as describe above, except that the C pre- + processor is invoked upon the .dtsp file before compiling the result + with dtc. + + In order for build dependencies to work, all files compiled using + dtc_cpp must use the C pre-processor's #include functionality and not + dtc's /include/ functionality. + + Using the C pre-processor allows use of #define to create named + constants. In turn, the #defines will typically appear in a header + file, which may be shared with regular C code. Since the dtc language + represents a data structure rather than code in C syntax, similar + restrictions are placed on a header file included by a device tree + file as for a header file included by an assembly language file. + In particular, the C pre-processor is passed -x assembler-with-cpp, + which sets macro __ASSEMBLY__. __DTS__ is also set. These allow header + files to restrict their content to that compatible with device tree + source. + + A central rule exists to create $(obj)/%.dtb from $(src)/%.dtsp; + architecture Makefiles do no need to explicitly write out that rule. + --- 6.8 Custom kbuild commands When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index bdf42fd..2c2a302 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -269,6 +269,15 @@ cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -d $(depfile $(obj)/%.dtb: $(src)/%.dts FORCE $(call if_changed_dep,dtc) +dtc-tmp = $(subst $(comma),_,$(dot-target).dts) + +quiet_cmd_dtc_cpp = DTC+CPP $@ +cmd_dtc_cpp = $(CPP) $(cpp_flags) -D__DTS__ -x assembler-with-cpp -o $(dtc-tmp) $ ; \ + $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $(dtc-tmp) + +$(obj)/%.dtb: $(src)/%.dtsp FORCE + $(call if_changed_dep,dtc_cpp) + # Bzip2 # --- -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/8] sh-pfc: Add OF support
Hi Laurent On Wed, 9 Jan 2013, Laurent Pinchart wrote: Support device instantiation through the device tree. The compatible property is used to select the SoC pinmux information. Set the gpio_chip device field to the PFC device to enable automatic GPIO OF support. Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Cc: devicetree-discuss@lists.ozlabs.org This whole pinctrl mega-series is a very welcome improvement to the sh-/r-mobile GPIO framework, and is very well done IMHO! But, unfortunately, as discussed with you privately yesterday, there is still a problem with pinctrl DT support on sh73a0, which will, probably, enforce an update to one or several of patches from this lot. To explain to other readers, on sh73a0 pin numbers are not contiguous, they are sparse. When pins are referred to from C code, macro names are used, which are then correctly decoded to respective positions in pin descriptor tables. Whereas with DT, pins are referred to from .dts files using their physical numbers, which then refer to either wrong or missing entries in those tables. I do not know where this problem should be solved best - either in descriptor tables, or in DT handling code, so, I don't know which patches would be affected. Don't think you'll want to keep the one-to-one index-to-pin mapping by also making pin-descriptor arrays sparse, so, so far I only see one possibility to fix this - by using the .enum_id field from struct sh_pfc_pin instead of just the index - both in C and in DT case, and those .enum_id values will have to provide physical pin numbers instead of plane indices. That way you'd have to update at least drivers/pinctrl/sh-pfc/pfc-sh73a0.c and the sh_pfc_map_gpios() function in drivers/pinctrl/sh-pfc/pinctrl.c. Anyway, I'm sure you'll find a suitable solution of this problem and for now I'll let Simon decide which patches he wants to apply and which ones he'd prefer to hold back;-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
On Saturday 12 January 2013, Thierry Reding wrote: I already hinted at that in one of the other subthreads. Having such a multiplex would also allow the driver to be built as a module. I had already thought about this when I was working on an earlier version of these patches. Basically these would be two ops attached to the host bridge, and the generic arch_setup_msi_irq() could then look that up given the struct pci_dev that is passed to it and call this new per- host bridge .setup_msi_irq(). struct pci_ops looks like a good place to put these. They'll be available from each struct pci_bus, so should be easy to call from arch_setup_msi_irq(). Any objections? struct pci_ops has a long history of being specifically about config space read/write operations, so on the one hand it does not feel like the right place to put interrupt specific operations, but on the other hand, the name sounds appropriate and I cannot think of any other place to put this, so it's fine with me. The only alternative I can think of is to introduce a new structure next to it in struct pci_bus, but that feels a bit pointless. Maybe Bjorn has a preference one way or the other. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] hwmon: Driver for Maxim MAX6697 and compatibles
Hi Guenter, On Fri, 11 Jan 2013 09:41:05 -0800, Guenter Roeck wrote: On Sun, Dec 16, 2012 at 09:33:09PM -0800, Guenter Roeck wrote: Add support for MAX6581, MAX6602, MAX6622, MAX6636, MAX6689, MAX6693, MAX6694, MAX6697, MAX6698, and MAX6699 temperature sensors Signed-off-by: Guenter Roeck li...@roeck-us.net I plan to line this driver up for 3.9. Only change from the code below is to replace SENSORS_LIMIT with clamp_val. Any objections, make yourself heard. I am in the process of reviewing this driver, I do have some comments and hope to be done by tomorrow evening. -- Jean Delvare ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/6] Initial Device Tree support for S3C64xx
This series is adds Device Tree support for Samsung S3C64xx SoC series. It fixes several problems preventing from booting an S3C64xx-based system using Device Tree, adds all the infrastructure for Device Tree-based board support, including mach-s3c64xx-dt and dts include files for S3C64xx SoCs, and (very) basic device tree source for FriendlyARM Mini6410 board. Current support is very limited and allows only basic bootup with UART and SDHCI, but should be fine as a start and will be extended in future, hopefully with help of S3C64xx board maintainers. Tomasz Figa (6): ARM: common: vic: Parse interrupt and resume masks from device tree ARM: common: vic: Fix invalid first IRQ number in OF-based registration ARM: s3c64xx: Add support for OF-based VIC initialization ARM: s3c64xx: Add board file for boot using Device Tree ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs ARM: dts: Add dts file for S3C6410-based Mini6410 board Documentation/devicetree/bindings/arm/vic.txt | 6 ++ arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/s3c6400.dtsi| 33 + arch/arm/boot/dts/s3c6410-mini6410.dts| 50 ++ arch/arm/boot/dts/s3c6410.dtsi| 33 + arch/arm/boot/dts/s3c64xx.dtsi| 97 +++ arch/arm/common/vic.c | 9 ++- arch/arm/mach-s3c64xx/Kconfig | 13 arch/arm/mach-s3c64xx/Makefile| 1 + arch/arm/mach-s3c64xx/common.c| 16 + arch/arm/mach-s3c64xx/common.h| 4 ++ arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 84 +++ 12 files changed, 345 insertions(+), 2 deletions(-) create mode 100644 arch/arm/boot/dts/s3c6400.dtsi create mode 100644 arch/arm/boot/dts/s3c6410-mini6410.dts create mode 100644 arch/arm/boot/dts/s3c6410.dtsi create mode 100644 arch/arm/boot/dts/s3c64xx.dtsi create mode 100644 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c -- 1.8.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/6] ARM: common: vic: Parse interrupt and resume masks from device tree
This patch extends vic_of_init to parse valid interrupt sources
and resume sources masks from device tree.
If mask values are not specified in device tree, all sources
are assumed to be valid, as before this patch.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
Documentation/devicetree/bindings/arm/vic.txt | 6 ++
arch/arm/common/vic.c | 7 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/vic.txt
b/Documentation/devicetree/bindings/arm/vic.txt
index 266716b..bb7137c 100644
--- a/Documentation/devicetree/bindings/arm/vic.txt
+++ b/Documentation/devicetree/bindings/arm/vic.txt
@@ -18,6 +18,9 @@ Required properties:
Optional properties:
- interrupts : Interrupt source for parent controllers if the VIC is nested.
+- interrupt-mask : Bit mask of valid interrupt sources (defaults to all valid)
+- wakeup-mask : Bit mask of interrupt sources that can wake up the system
+ (defaults to all allowed)
Example:
@@ -26,4 +29,7 @@ Example:
interrupt-controller;
#interrupt-cells = 1;
reg = 0x6 0x1000;
+
+ interrupt-mask = 0xff7f;
+ wakeup-mask = 0xff7f;
};
diff --git a/arch/arm/common/vic.c b/arch/arm/common/vic.c
index e4df17c..c2889da 100644
--- a/arch/arm/common/vic.c
+++ b/arch/arm/common/vic.c
@@ -407,6 +407,8 @@ void __init vic_init(void __iomem *base, unsigned int
irq_start,
int __init vic_of_init(struct device_node *node, struct device_node *parent)
{
void __iomem *regs;
+ u32 interrupt_mask = ~0;
+ u32 wakeup_mask = ~0;
if (WARN(parent, non-root VICs are not supported))
return -EINVAL;
@@ -415,10 +417,13 @@ int __init vic_of_init(struct device_node *node, struct
device_node *parent)
if (WARN_ON(!regs))
return -EIO;
+ of_property_read_u32(node, interrupt-mask, interrupt_mask);
+ of_property_read_u32(node, wakeup-mask, wakeup_mask);
+
/*
* Passing -1 as first IRQ makes the simple domain allocate descriptors
*/
- __vic_init(regs, -1, ~0, ~0, node);
+ __vic_init(regs, -1, interrupt_mask, wakeup_mask, node);
return 0;
}
--
1.8.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/6] ARM: common: vic: Fix invalid first IRQ number in OF-based registration
Without this patch, vic_of_init passed -1 as first IRQ number to __vic_init (as signed int), then to vic_register (now as unsigned int equals to 0x) and finally to irq_domain_add_simple (again as unsigned 0x), which tries to allocate irq descriptors starting from IRQ 0x, which obviously is bound to fail. This patch corrects OF-based VIC registration by locating VICs in IRQ address space starting from IRQ 32 and then placing one VIC after another. This is similar to the solution used with GIC and allows to maintain compatibility with legacy code using static IRQ numbers. Signed-off-by: Tomasz Figa tomasz.f...@gmail.com --- arch/arm/common/vic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/common/vic.c b/arch/arm/common/vic.c index c2889da..8001994 100644 --- a/arch/arm/common/vic.c +++ b/arch/arm/common/vic.c @@ -421,9 +421,9 @@ int __init vic_of_init(struct device_node *node, struct device_node *parent) of_property_read_u32(node, wakeup-mask, wakeup_mask); /* -* Passing -1 as first IRQ makes the simple domain allocate descriptors +* Use IRQ numbers starting from 32 and placing each VIC after another */ - __vic_init(regs, -1, interrupt_mask, wakeup_mask, node); + __vic_init(regs, 32 + (32 * vic_id), interrupt_mask, wakeup_mask, node); return 0; } -- 1.8.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/6] ARM: s3c64xx: Add support for OF-based VIC initialization
This patch modifies IRQ initialization code of S3C64xx to support
Device Tree-based initialization of VICs.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
arch/arm/mach-s3c64xx/common.c | 16
arch/arm/mach-s3c64xx/common.h | 4
2 files changed, 20 insertions(+)
diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index aef303b..b9c5bec 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -19,6 +19,7 @@
#include linux/module.h
#include linux/interrupt.h
#include linux/ioport.h
+#include linux/of_irq.h
#include linux/serial_core.h
#include linux/platform_device.h
#include linux/io.h
@@ -181,6 +182,21 @@ core_initcall(s3c64xx_dev_init);
1 (IRQ_HSMMC1 - IRQ_VIC1_BASE) |\
1 (IRQ_HSMMC2 - IRQ_VIC1_BASE))
+#ifdef CONFIG_OF
+static const struct of_device_id s3c64xx_dt_irq_match[] = {
+ { .compatible = arm,pl192-vic, .data = vic_of_init, },
+ {},
+};
+
+void __init s3c64xx_of_init_irq(void)
+{
+ of_irq_init(s3c64xx_dt_irq_match);
+
+ /* FIXME: add the timer sub-irqs */
+ s3c_init_vic_timer_irq(5, IRQ_TIMER0);
+}
+#endif
+
void __init s3c64xx_init_irq(u32 vic0_valid, u32 vic1_valid)
{
printk(KERN_DEBUG %s: initialising interrupts\n, __func__);
diff --git a/arch/arm/mach-s3c64xx/common.h b/arch/arm/mach-s3c64xx/common.h
index 6cfc99b..711f3e0 100644
--- a/arch/arm/mach-s3c64xx/common.h
+++ b/arch/arm/mach-s3c64xx/common.h
@@ -58,4 +58,8 @@ int __init s3c64xx_pm_late_initcall(void);
static inline int s3c64xx_pm_late_initcall(void) { return 0; }
#endif
+#ifdef CONFIG_OF
+extern void s3c64xx_of_init_irq(void);
+#endif
+
#endif /* __ARCH_ARM_MACH_S3C64XX_COMMON_H */
--
1.8.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/6] ARM: s3c64xx: Add board file for boot using Device Tree
This patch adds board file that will be used to boot S3C64xx-based boards
using Device Tree.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
arch/arm/mach-s3c64xx/Kconfig | 13 +
arch/arm/mach-s3c64xx/Makefile | 1 +
arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 84 +
3 files changed, 98 insertions(+)
create mode 100644 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 283cb77..b1c7106 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -311,3 +311,16 @@ config MACH_WLF_CRAGG_6410
select SAMSUNG_GPIO_EXTRA128
help
Machine support for the Wolfson Cragganmore S3C6410 variant.
+
+config MACH_S3C64XX_DT
+ bool Samsung S3C6400/S3C6410 machine using Device Tree
+ select CPU_S3C6400
+ select CPU_S3C6410
+ select USE_OF
+ help
+ Machine support for Samsung S3C6400/S3C6410 machines with Device Tree
+ enabled.
+ Select this if a fdt blob is available for your S3C64XX SoC based
+ board.
+ Note: This is under development and not all peripherals can be
+ supported with this machine file.
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index f9ce1dc..59b3d06 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -58,3 +58,4 @@ obj-$(CONFIG_MACH_SMARTQ7)+= mach-smartq7.o
obj-$(CONFIG_MACH_SMDK6400)+= mach-smdk6400.o
obj-$(CONFIG_MACH_SMDK6410)+= mach-smdk6410.o
obj-$(CONFIG_MACH_WLF_CRAGG_6410) += mach-crag6410.o
mach-crag6410-module.o
+obj-$(CONFIG_MACH_S3C64XX_DT) += mach-s3c64xx-dt.o
diff --git a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
new file mode 100644
index 000..974af2a
--- /dev/null
+++ b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
@@ -0,0 +1,84 @@
+/*
+ * Samsung's S3C64XX flattened device tree enabled machine
+ *
+ * Copyright (c) 2013 Tomasz Figa tomasz.f...@gmail.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 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/of_platform.h
+#include linux/serial_core.h
+
+#include asm/mach/arch.h
+#include asm/hardware/vic.h
+#include mach/map.h
+
+#include plat/cpu.h
+#include plat/regs-serial.h
+#include plat/samsung-time.h
+
+#include common.h
+
+/*
+ * The following lookup table is used to override device names when devices
+ * are registered from device tree. This is temporarily added to enable
+ * device tree support addition for the S3C64xx architecture.
+ *
+ * For drivers that require platform data to be provided from the machine
+ * file, a platform data pointer can also be supplied along with the
+ * devices names. Usually, the platform data elements that cannot be parsed
+ * from the device tree by the drivers (example: function pointers) are
+ * supplied. But it should be noted that this is a temporary mechanism and
+ * at some point, the drivers should be capable of parsing all the platform
+ * data from the device tree.
+ */
+static const struct of_dev_auxdata s3c64xx_auxdata_lookup[] __initconst = {
+ OF_DEV_AUXDATA(samsung,s3c6400-uart, 0x7f005000,
+ s3c6400-uart.0, NULL),
+ OF_DEV_AUXDATA(samsung,s3c6400-uart, 0x7f005400,
+ s3c6400-uart.1, NULL),
+ OF_DEV_AUXDATA(samsung,s3c6400-uart, 0x7f005800,
+ s3c6400-uart.2, NULL),
+ OF_DEV_AUXDATA(samsung,s3c6400-uart, 0x7f005c00,
+ s3c6400-uart.3, NULL),
+ OF_DEV_AUXDATA(samsung,s3c6410-sdhci, 0x7c20,
+ s3c-sdhci.0, NULL),
+ OF_DEV_AUXDATA(samsung,s3c6410-sdhci, 0x7c30,
+ s3c-sdhci.1, NULL),
+ OF_DEV_AUXDATA(samsung,s3c6410-sdhci, 0x7c40,
+ s3c-sdhci.2, NULL),
+ {},
+};
+
+static void __init s3c64xx_dt_map_io(void)
+{
+ s3c64xx_init_io(NULL, 0);
+ s3c24xx_init_clocks(1200);
+ samsung_set_timer_source(SAMSUNG_PWM3, SAMSUNG_PWM4);
+}
+
+static void __init s3c64xx_dt_machine_init(void)
+{
+ of_platform_populate(NULL, of_default_bus_match_table,
+ s3c64xx_auxdata_lookup, NULL);
+}
+
+static char const *s3c64xx_dt_compat[] __initdata = {
+ samsung,s3c6400,
+ samsung,s3c6410,
+ NULL
+};
+
+DT_MACHINE_START(S3C6400_DT, Samsung S3C64xx (Flattened Device Tree))
+ /* Maintainer: Tomasz Figa tomasz.f...@gmail.com */
+ .init_irq = s3c64xx_of_init_irq,
+ .map_io = s3c64xx_dt_map_io,
+ .handle_irq = vic_handle_irq,
+ .init_machine = s3c64xx_dt_machine_init,
+ .init_late = s3c64xx_init_late,
+
[PATCH 5/6] ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs
This patch adds basic device tree definitions for Samsung S3C64xx SoCs.
Since all the SoCs in the series are very similar, the files are created
hierarchically - one file for the whole series and then separate files
for particular SoCs including the common one.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
arch/arm/boot/dts/s3c6400.dtsi | 33 ++
arch/arm/boot/dts/s3c6410.dtsi | 33 ++
arch/arm/boot/dts/s3c64xx.dtsi | 97 ++
3 files changed, 163 insertions(+)
create mode 100644 arch/arm/boot/dts/s3c6400.dtsi
create mode 100644 arch/arm/boot/dts/s3c6410.dtsi
create mode 100644 arch/arm/boot/dts/s3c64xx.dtsi
diff --git a/arch/arm/boot/dts/s3c6400.dtsi b/arch/arm/boot/dts/s3c6400.dtsi
new file mode 100644
index 000..76106b8
--- /dev/null
+++ b/arch/arm/boot/dts/s3c6400.dtsi
@@ -0,0 +1,33 @@
+/*
+ * Samsung's S3C6400 SoC device tree source
+ *
+ * Copyright (c) 2013 Tomasz Figa tomasz.f...@gmail.com
+ *
+ * Samsung's S3C6400 SoC device nodes are listed in this file. S3C6400
+ * based board files can include this file and provide values for board specfic
+ * bindings.
+ *
+ * Note: This file does not include device nodes for all the controllers in
+ * S3C6400 SoC. As device tree coverage for S3C6400 increases, additional
+ * nodes can be added to this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/include/ s3c64xx.dtsi
+
+/ {
+ compatible = samsung,s3c6400;
+
+ vic0: interrupt-controller@7120 {
+ interrupt-mask = 0xfe1f;
+ wakeup-mask = 0x0024;
+ };
+
+ vic1: interrupt-controller@7130 {
+ interrupt-mask = 0x;
+ wakeup-mask = 0x5302;
+ };
+};
diff --git a/arch/arm/boot/dts/s3c6410.dtsi b/arch/arm/boot/dts/s3c6410.dtsi
new file mode 100644
index 000..4a74df9
--- /dev/null
+++ b/arch/arm/boot/dts/s3c6410.dtsi
@@ -0,0 +1,33 @@
+/*
+ * Samsung's S3C6410 SoC device tree source
+ *
+ * Copyright (c) 2013 Tomasz Figa tomasz.f...@gmail.com
+ *
+ * Samsung's S3C6410 SoC device nodes are listed in this file. S3C6410
+ * based board files can include this file and provide values for board specfic
+ * bindings.
+ *
+ * Note: This file does not include device nodes for all the controllers in
+ * S3C6410 SoC. As device tree coverage for S3C6410 increases, additional
+ * nodes can be added to this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/include/ s3c64xx.dtsi
+
+/ {
+ compatible = samsung,s3c6410;
+
+ vic0: interrupt-controller@7120 {
+ interrupt-mask = 0xff7f;
+ wakeup-mask = 0x0024;
+ };
+
+ vic1: interrupt-controller@7130 {
+ interrupt-mask = 0x;
+ wakeup-mask = 0x5302;
+ };
+};
diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
new file mode 100644
index 000..55d6e08
--- /dev/null
+++ b/arch/arm/boot/dts/s3c64xx.dtsi
@@ -0,0 +1,97 @@
+/*
+ * Samsung's S3C64xx SoC series common device tree source
+ *
+ * Copyright (c) 2013 Tomasz Figa tomasz.f...@gmail.com
+ *
+ * Samsung's S3C64xx SoC series device nodes are listed in this file.
+ * Particular SoCs from S3C64xx series can include this file and provide
+ * values for SoCs specfic bindings.
+ *
+ * Note: This file does not include device nodes for all the controllers in
+ * S3C64xx SoCs. As device tree coverage for S3C64xx increases, additional
+ * nodes can be added to this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/include/ skeleton.dtsi
+
+/ {
+ cpus {
+ cpu@0 {
+ compatible = arm,arm1176jzf-s;
+ };
+ };
+
+ vic0: interrupt-controller@7120 {
+ compatible = arm,pl192-vic;
+ interrupt-controller;
+ reg = 0x7120 0x1000;
+ #interrupt-cells = 1;
+ };
+
+ vic1: interrupt-controller@7130 {
+ compatible = arm,pl192-vic;
+ interrupt-controller;
+ reg = 0x7130 0x1000;
+ #interrupt-cells = 1;
+ };
+
+ serial@7f005000 {
+ compatible = samsung,s3c6400-uart;
+ reg = 0x7f005000 0x100;
+ interrupt-parent = vic1;
+ interrupts = 5 0;
+ status = disabled;
+ };
+
+ serial@7f005400 {
+ compatible = samsung,s3c6400-uart;
+ reg = 0x7f005400 0x100;
+
[PATCH 6/6] ARM: dts: Add dts file for S3C6410-based Mini6410 board
This patch adds basic device tree sources for FriendlyARM Mini6410 board
based on Samsung S3C6410 SoC.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/s3c6410-mini6410.dts | 50 ++
2 files changed, 51 insertions(+)
create mode 100644 arch/arm/boot/dts/s3c6410-mini6410.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e44da40..9ca30ea 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -120,6 +120,7 @@ dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
hrefprev60.dtb \
hrefv60plus.dtb \
ccu9540.dtb
+dtb-$(CONFIG_ARCH_S3C64XX) += s3c6410-mini6410.dtb
dtb-$(CONFIG_ARCH_SHMOBILE) += emev2-kzm9d.dtb \
r8a7740-armadillo800eva.dtb \
sh73a0-kzm9g.dtb \
diff --git a/arch/arm/boot/dts/s3c6410-mini6410.dts
b/arch/arm/boot/dts/s3c6410-mini6410.dts
new file mode 100644
index 000..9ac82c2
--- /dev/null
+++ b/arch/arm/boot/dts/s3c6410-mini6410.dts
@@ -0,0 +1,50 @@
+/*
+ * Samsung's S3C6410 based Mini6410 board device tree source
+ *
+ * Copyright (c) 2013 Tomasz Figa tomasz.f...@gmail.com
+ *
+ * Device tree source file for FriendlyARM Mini6410 board which is based on
+ * Samsung's S3C6410 SoC.
+ *
+ * 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.
+*/
+
+/dts-v1/;
+/include/ s3c6410.dtsi
+
+/ {
+ model = FriendlyARM Mini6410 board based on S3C6410;
+ compatible = friendlyarm,mini6410, samsung,s3c6410;
+
+ memory {
+ reg = 0x5000 0x1000;
+ };
+
+ chosen {
+ bootargs = console=ttySAC0,115200n8 earlyprintk rootwait
root=/dev/mmcblk0p1;
+ };
+
+ serial@7f005000 {
+ status = okay;
+ };
+
+ serial@7f005400 {
+ status = okay;
+ };
+
+ serial@7f005800 {
+ status = okay;
+ };
+
+ serial@7f005c00 {
+ status = okay;
+ };
+
+ sdhci@7c20 {
+ bus-width = 4;
+ non-removable;
+ status = okay;
+ };
+};
--
1.8.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of_i2c: I2C child node 10-bit client addressing
FYI, re: https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-November/022645.html I know that was a long time ago, but I was searching for information on which chips supported 10-bit I2C addresses, and found a partial answer to the question: Grant Likely wrote: Is it possible for a device to have an address that fits in the first 7 bits, but still requires 10 bit address transactions? The following chip (link below) certainly supports a 10-bit I2C address with the top-most 3 bits set to 0. Now, it does also respond to a 7-bit I2C address of the same value, so this perhaps isn't quite an exact answer to Grant's question. However, it does indicate to me that we shouldn't determine whether to use 7- or 10-bit addresses solely from the set bits in the I2C address; a separate property or flag bit in the address field would be better, I think. http://www.ti.com/lit/ds/snvs839/snvs839.pdf Quoting it: 7-BIT and 10-BIT ADDRESSING MODES The LM8330 supports both the 7-bit and 10-bit addressing modes as defined in the NXP (Philips) I 2 C Specification UM10204 rev 0.3 from 2007. The default 7-bit slave address is 0x88, and the default 10-bit slave address is 0x088. NOTE: The upper three address bits in 10-bit mode are hard tied to 0. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: PMU node location
On 01/12/2013 08:54 AM, Rob Herring wrote: On 01/10/2013 07:47 AM, Michal Simek wrote: Hi Rob, Mark, Grant and others, I want to check with you the location of ARM pmu node I see that 1) highbank and dbx5x0 have it in soc node 2) vexpress and tegra have no main bus and pmu is in root like all others devices. (Any reason no to have main bus? Does it mean that there is no bus or that all devices are accessible?) That seems really wrong in general. Any memory mapped device is on a bus of some kind. I'm not sure the reasoning. Perhaps Stephen can explain. I saw no need to have add a bus node (there wasn't one before I started touching DT on Tegra); the top-level of the DT represents the CPU's entire view of the address space and has #address-cells/#size-cells, so devices get probed there just fine, whether they're addressed MMIO devices or not. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
