Re: [PATCH V2 2/2] Input: spear-keyboard: add device tree bindings
Hi Viresh,
On Tue, Mar 27, 2012 at 11:08:12AM +0530, Viresh Kumar wrote:
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev, DT: kzalloc failed\n);
+ return -ENOMEM;
+ }
+
+ pdev-dev.platform_data = pdata;
+ error = spear_kbd_probe_dt(pdev);
+ if (error) {
+ dev_err(pdev-dev, DT: no platform data\n);
+ return error;
+ }
+ } else {
+ pdata = dev_get_platdata(pdev-dev);
+ if (!pdata || !pdata-keymap) {
+ dev_err(pdev-dev, Invalid platform data\n);
+ return -EINVAL;
+ }
}
I think the opposite order woudl make more sense - if pdata is supplied
by the platform code then we should use it, otherwise try to see if
there is OF data available instead. This way one can easily override OF
data, if needed.
Same goes for keymap data.
Thanks.
--
Dmitry
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 2/2] Input: spear-keyboard: add device tree bindings
On 3/27/2012 12:43 PM, Dmitry Torokhov wrote: I think the opposite order woudl make more sense - if pdata is supplied by the platform code then we should use it, otherwise try to see if there is OF data available instead. This way one can easily override OF data, if needed. Okay. Just for better understanding, why should we give more preference to pdata? I thought, a single image with pdata can be booted with or without DT support for keyboard. So, if we are booting without of DT for keyboard, then use pdata, otherwise use DT data. -- viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 2/2] Input: spear-keyboard: add device tree bindings
On Tue, Mar 27, 2012 at 01:07:51PM +0530, Viresh Kumar wrote: On 3/27/2012 12:43 PM, Dmitry Torokhov wrote: I think the opposite order woudl make more sense - if pdata is supplied by the platform code then we should use it, otherwise try to see if there is OF data available instead. This way one can easily override OF data, if needed. Okay. Just for better understanding, why should we give more preference to pdata? I thought, a single image with pdata can be booted with or without DT support for keyboard. So, if we are booting without of DT for keyboard, then use pdata, otherwise use DT data. My reasoning is that device tree is in firmware and it might be desirable to override firmware in certain cases. Thanks. -- Dmitry ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 2/2] Input: spear-keyboard: add device tree bindings
On 3/27/2012 1:21 PM, Dmitry Torokhov wrote: My reasoning is that device tree is in firmware and it might be desirable to override firmware in certain cases. Ok. Will do that. Otherwise, you are okay with both the patches? So that i can send V3. -- viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: kirkwood devicetree respin
Hi, On Thu, Mar 22, 2012 at 06:28:26PM +, Paul Zimmerman wrote: context, toggle clocks, set pads in safe mode (when needed) and so on. But fair enough, both ways would work fine. I would also recommend your/Alan's approach to this over Felipe's way. We have a DWC3 platform with an (admittedly oddball) PM implementation that requires the bus driver to have some knowledge of the base driver's internal state, and needs the two drivers to be able to communicate with each other. With the base driver being a separate platform device, this is nearly impossible to achieve in a clean way. If the DWC3 driver was designed the way you and Alan are recommending, it would be easy. I'm trying to convince Felipe to change the DWC3 driver design to accommodate this, but I hold out little hope for that :) yeah, I'm not thinking on taking that patch, sorry. Didn't you say SNPS had agreed on rebuilding the FPGA system so that it's a more standard PCIe implementation ? I still owe you another possible implementation for the whole PM thing, sorry about the delay. Dropped the other folks from CC since they probably aren't interested. The FPGA rework is very low priority, those guys have more important stuff to work on at the moment. Plus management doesn't understand why the current design won't work, since the Synopsys driver supports it OK. So I'm not sure when the FPGA rework will happen. Ok, so let's work with what we have now. I'll try to shuffle your patches around to the way I think they could/should be done, but I'll need your help testing since I don't have any hibernation-enabled version of the IP at hand. Hope it's ok with you ;-) -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: SPEAr600: Add device-tree support to SPEAr600 boards
On 3/22/2012 7:50 PM, Arnd Bergmann wrote: The direct replacement is of_machine_is_compatible(), but there are a lot of cases where it's better to have a local property in the device node that a driver is using. Hey Arnd, I used of_machine_is_compatible() at several places, where it is not working :( Actually all these usages are before a call to of_platform_populate() and it looks the tree is not up by this time. So, of_machine_is_compatible() always fails. The places where i am using this routine are: - spear3xx_dt_init(): to call SoC specific of_platform_populate() - spear3xx_clk_init(): to call SoC specific clk_register() Can you please suggest what should i do here? -- viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: SPEAr600: Add device-tree support to SPEAr600 boards
On Tuesday 27 March 2012, Viresh Kumar wrote:
On 3/22/2012 7:50 PM, Arnd Bergmann wrote:
The direct replacement is of_machine_is_compatible(), but there are a lot
of cases where it's better to have a local property in the device node
that a driver is using.
Hey Arnd,
I used of_machine_is_compatible() at several places, where it is not working
:(
Actually all these usages are before a call to of_platform_populate() and
it looks the tree is not up by this time.
So, of_machine_is_compatible() always fails. The places where i am using this
routine are:
- spear3xx_dt_init(): to call SoC specific of_platform_populate()
- spear3xx_clk_init(): to call SoC specific clk_register()
Can you please suggest what should i do here?
The normal way is to turn around the logic so you don't have to include this
test
at all. Just have one soc-specific init_machine and map_io function, that calls
both soc-specific and shared soc functions, e.g.
void __init spear3xx_clk_init(void)
{
int i;
struct clk_lookup *lookups;
for (i = 0; i ARRAY_SIZE(spear3xx_clk_lookups); i++)
clk_register(spear3xx_clk_lookups[i])
}
void __init spear300_clk_init(void)
{
int i;
struct clk_lookup *lookups;
spear3xx_clk_init();
for (i = 0; i ARRAY_SIZE(spear300_clk_lookups); i++)
clk_register(spear300_clk_lookups[i])
clk_init();
}
void __init spear300_map_io(void)
{
spear3xx_map_io();
spear300_clk_init();
}
The other option would be to try to move stuff to a later point, e.g. don't
initialize the clocks until the basic device tree is set up.
of_machine_is_compatible() should work at init_early() time, but not at
map_io() time. Other platforms set up the clocks at init_early() time.
The spear3xx_dt_init function should be called from init_machine(), which
happens much later, so I'm pretty sure you can use of_machine_is_compatible()
if you can't just avoid it.
In the long run, I would hope that a lot of the differences go away anyway
as information that is now hardcoded just moves into the device tree.
At that point, you should no longer need to care which soc you are running
on. I realize that there is still significant amount of work to be done
until you get there.
In case of the clocks, I think you could already merge all the clk_lookup
arrays into one, which would result in a larger kernel image but should
do no harm otherwise.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: SPEAr600: Add device-tree support to SPEAr600 boards
On 3/27/2012 4:45 PM, Arnd Bergmann wrote:
On Tuesday 27 March 2012, Viresh Kumar wrote:
The normal way is to turn around the logic so you don't have to include this
test
at all. Just have one soc-specific init_machine and map_io function, that
calls
both soc-specific and shared soc functions, e.g.
But with that, i need multiple DT_MACHINE_START(). Isn't it?
Is this advisable?
The other option would be to try to move stuff to a later point, e.g. don't
initialize the clocks until the basic device tree is set up.
of_machine_is_compatible() should work at init_early() time, but not at
map_io() time. Other platforms set up the clocks at init_early() time.
The spear3xx_dt_init function should be called from init_machine(), which
happens much later, so I'm pretty sure you can use of_machine_is_compatible()
if you can't just avoid it.
DT should be up but, nodes would be up only once we call
of_platform_populate() from this init routine. And i had following code in
my patch:
static void __init spear3xx_dt_init(void)
{
...
if (of_machine_is_compatible(st,spear300))
of_platform_populate(NULL, of_default_bus_match_table,
spear300_auxdata_lookup, NULL);
else if (of_machine_is_compatible(st,spear310))
of_platform_populate(NULL, of_default_bus_match_table,
spear310_auxdata_lookup, NULL);
else if (of_machine_is_compatible(st,spear320))
of_platform_populate(NULL, of_default_bus_match_table,
spear320_auxdata_lookup, NULL);
...
}
And so these checks are not working here. :(
In case of the clocks, I think you could already merge all the clk_lookup
arrays into one, which would result in a larger kernel image but should
do no harm otherwise.
Actually we can't do it. :(
If i boot 300 then i will also get clocks of 310 and 320 in my clock list.
And once i go through this clock list to create clock tree (parent-child
relationship), i will try to access hardware registers of 310 320,
which are just not valid for 300. Kernel Crash!!
--
viresh
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: SPEAr600: Add device-tree support to SPEAr600 boards
On Tuesday 27 March 2012, Viresh Kumar wrote: On 3/27/2012 4:45 PM, Arnd Bergmann wrote: On Tuesday 27 March 2012, Viresh Kumar wrote: The normal way is to turn around the logic so you don't have to include this test at all. Just have one soc-specific init_machine and map_io function, that calls both soc-specific and shared soc functions, e.g. But with that, i need multiple DT_MACHINE_START(). Isn't it? Is this advisable? Having one DT_MACHINE_START per soc is ok if it helps you. Of course if you have multiple ones that are basically identical, it's simpler to just combine them. In case of the clocks, I think you could already merge all the clk_lookup arrays into one, which would result in a larger kernel image but should do no harm otherwise. Actually we can't do it. :( If i boot 300 then i will also get clocks of 310 and 320 in my clock list. And once i go through this clock list to create clock tree (parent-child relationship), i will try to access hardware registers of 310 320, which are just not valid for 300. Kernel Crash!! Ok, I see. BTW, have you tried what I first recommended to you, which is to check the compatible property of the clock node instead of the machine? Obviously that only works when you initialize the clocks from init_early() instead of from map_io(), but I think that would be the cleanest choice if you want to have single function with run-time dependencies. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/2] Input: of_keymap: Introduce matrix_keypad_of_build_keymap()
On 03/26/2012 11:38 PM, Viresh Kumar wrote:
We don't need to allocate memory for keymap in
matrix_keyboard_of_fill_keymap(),
as this would only be used by matrix_keyboard_of_free_keymap(). Instead create
another routine matrix_keypad_of_build_keymap() which reads directly the
property from struct device_node and builds keymap.
With this eariler routines matrix_keyboard_of_fill_keymap() and
matrix_keyboard_of_free_keymap() go away.
This patch also fixes tegra driver according to these changes.
diff --git a/drivers/input/keyboard/tegra-kbc.c
b/drivers/input/keyboard/tegra-kbc.c
...
static int __devinit tegra_kbc_probe(struct platform_device *pdev)
...
+ if (pdev-dev.of_node) {
+ /* FIXME: Add handling of linux,fn-keymap here */
+ err = matrix_keypad_of_build_keymap(pdev-dev, KBC_ROW_SHIFT,
+ input_dev-keycode, input_dev-keybit,
+ linux,keymap);
Where do input_dev-keycode/keybit get allocated? As far as I can tell,
matrix_keypad_of_build_keymap() just writes to those and assumes they're
already allocated.
diff --git a/drivers/input/of_keymap.c b/drivers/input/of_keymap.c
...
+int matrix_keypad_of_build_keymap(struct device *dev, unsigned int row_shift,
...
+ keymap[MATRIX_SCAN_CODE(row, col, row_shift)] = code;
+ __set_bit(code, keybit);
How bit are keymap and keybit? I think we need range-checking here to
make sure that row/col/row_shift/code are valid and in-range.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 2/2] Input: spear-keyboard: add device tree bindings
On 03/26/2012 11:38 PM, Viresh Kumar wrote: This adds simple DT bindings for spear-keyboard controller. Signed-off-by: Viresh Kumar viresh.ku...@st.com The binding documentation only, Reviewed-by: Stephen Warren swar...@wwwdotorg.org ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Hi Kukjin, On Tue, Feb 21 2012, Chris Ball wrote: On Tue, Feb 21 2012, Kukjin Kim wrote: I created topic branch for this we talked. You can pull that following: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.4-for-cjb If any problems, please kindly let me know. Pushed to mmc-next, thanks. (I'm expecting that you'll do the merge to Linus.) I was expecting you to merge these patches, but they aren't in the arm-soc tree and haven't been sent to Linus, and we're in the last few days of the merge window. As a result I'm dropping this tree -- and all of the patches that I have on top of it -- from mmc-next so that I can get a pull request out. This means that I'm dropping: mmc: sdhci-s3c: Add device tree support mmc: sdhci-s3c: Keep a copy of platform data and use it mmc: sdhci-s3c: derive transfer width host capability from max_width in ARM: SAMSUNG: remove all uses of clk_type member in sdhci platform data ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci controllers mmc: sdhci-s3c: Remove usage of clk_type member in platform data .. which I was expecting you to merge, and also: mmc: sdhci-s3c: fix broken compilation for non-Exynos SoCs mmc: sdhci-s3c: Enable runtime power management mmc: sdhci-s3c: Use CONFIG_PM_SLEEP to ifdef system suspend mmc: sdhci-s3c: use devm_ functions .. which were merged on top of the above patches. We'll have to try again with 3.5 for the new features, and post-rc1 for the fixes. Please let me know what happened with this merge. Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 6/6] mmc: sdhci-s3c: Add device tree support
On Tuesday 31 January 2012, Thomas Abraham wrote: + +Optional Board Specific Properties: +- samsung,sdhci-bus-width: Number of data lines connected to the controller. + Note: This excludes the clock,command and card detect lines. If this property + is not specified, default value is 1. + +- samsung,cd-gpio-invert: If 'samsung,sdhci-cd-gpio' card detect method is + selected, this property can be optionally specified to invert the value of + external card detect gpio line. + +- One of the following properties for card detect type. + - samsung,sdhci-cd-internal: Card detect line from the card slot is +connected to the card detect pad of the sdhci controller. A gpio is +used for this connection (with possible pin function settings). + - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings) +is used a card detect line. This gpio line is not connected to card detect +pad of the sdhci controller. + - samsung,sdhci-cd-none: There is no card detect line. Polling is used to +detect the presence of the card. (DEFAULT, if no card detect property +is specified). + - samsung,sdhci-cd-permanent: There is no card detect line. The card is +permanently connected to the sdhci controller. + +- gpio-cd: The gpio to be used as card detect line for + 'samsung,sdhci-cd-internal' or 'samsung,sdhci-cd-gpio' card detection method. + The gpio specifier format depends on the gpio controller. These bindings came up in a discussion IRC today. I think it's rather bad that we can't agree on a common way to name the properties for mmc. We have bindings being proposed or already included from Anton, Stephen, Shawn, Rajendra, Viresh, Lee and Thomas. Almost all of them define GPIO pins for card detect and write protect, as well properties to define the bus width and high-speed modes, but we seem to have almost as many different definitions of these as we have drivers. Can we please come up with a common binding for these? Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 6/6] mmc: sdhci-s3c: Add device tree support
On Tuesday 31 January 2012, Thomas Abraham wrote: + +Optional Board Specific Properties: +- samsung,sdhci-bus-width: Number of data lines connected to the controller. + Note: This excludes the clock,command and card detect lines. If this property + is not specified, default value is 1. + +- samsung,cd-gpio-invert: If 'samsung,sdhci-cd-gpio' card detect method is + selected, this property can be optionally specified to invert the value of + external card detect gpio line. + +- One of the following properties for card detect type. + - samsung,sdhci-cd-internal: Card detect line from the card slot is +connected to the card detect pad of the sdhci controller. A gpio is +used for this connection (with possible pin function settings). + - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings) +is used a card detect line. This gpio line is not connected to card detect +pad of the sdhci controller. + - samsung,sdhci-cd-none: There is no card detect line. Polling is used to +detect the presence of the card. (DEFAULT, if no card detect property +is specified). + - samsung,sdhci-cd-permanent: There is no card detect line. The card is +permanently connected to the sdhci controller. + +- gpio-cd: The gpio to be used as card detect line for + 'samsung,sdhci-cd-internal' or 'samsung,sdhci-cd-gpio' card detection method. + The gpio specifier format depends on the gpio controller. These bindings came up in a discussion IRC today. I think it's rather bad that we can't agree on a common way to name the properties for mmc. We have bindings being proposed or already included from Anton, Stephen, Shawn, Rajendra, Viresh, Lee and Thomas. Almost all of them define GPIO pins for card detect and write protect, as well properties to define the bus width and high-speed modes, but we seem to have almost as many different definitions of these as we have drivers. Can we please come up with a common binding for these? Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 2/4] MIPS: Octeon: Setup irq_domains for interrupts.
On 03/26/2012 06:56 PM, Rob Herring wrote:
On 03/26/2012 02:31 PM, David Daney wrote:
From: David Daneydavid.da...@cavium.com
[...]
+static bool octeon_irq_ciu_is_edge(unsigned int line, unsigned int bit)
+{
+ bool edge = false;
+
+ if (line == 0)
+ switch (bit) {
+ case 48 ... 49: /* GMX DRP */
+ case 50: /* IPD_DRP */
+ case 52 ... 55: /* Timers */
+ case 58: /* MPI */
+ edge = true;
+ break;
+ default:
+ break;
+ }
+ else /* line == 1 */
+ switch (bit) {
+ case 47: /* PTP */
+ edge = true;
+ break;
+ default:
+ break;
+ }
+ return edge;
Moving in the right direction, but I still don't get why this is not in
the CIU binding as a 3rd cell?
There are a several reasons, in no particular order they are:
o There is no 3rd cell. The bindings were discussed with Grant here:
http://www.linux-mips.org/archives/linux-mips/2011-05/msg00355.html
o The edge/level thing cannot be changed, and the irq lines don't leave
the SOC, so hard coding it is possible.
+}
+
+struct octeon_irq_gpio_domain_data {
+ unsigned int base_hwirq;
+};
+
+static int octeon_irq_gpio_xlat(struct irq_domain *d,
+ struct device_node *node,
+ const u32 *intspec,
+ unsigned int intsize,
+ unsigned long *out_hwirq,
+ unsigned int *out_type)
+{
+ unsigned int type;
+ unsigned int pin;
+ unsigned int trigger;
+ bool set_edge_handler = false;
+ struct octeon_irq_gpio_domain_data *gpiod;
+
+ if (d-of_node != node)
+ return -EINVAL;
+
+ if (intsize 2)
+ return -EINVAL;
+
+ pin = intspec[0];
+ if (pin= 16)
+ return -EINVAL;
+
+ trigger = intspec[1];
+
+ switch (trigger) {
+ case 1:
+ type = IRQ_TYPE_EDGE_RISING;
+ set_edge_handler = true;
This is never used.
Right, it was leftover from the previous version.
+ break;
+ case 2:
+ type = IRQ_TYPE_EDGE_FALLING;
+ set_edge_handler = true;
+ break;
+ case 4:
+ type = IRQ_TYPE_LEVEL_HIGH;
+ break;
+ case 8:
+ type = IRQ_TYPE_LEVEL_LOW;
+ break;
+ default:
+ pr_err(Error: (%s) Invalid irq trigger specification: %x\n,
+ node-name,
+ trigger);
+ type = IRQ_TYPE_LEVEL_LOW;
+ break;
+ }
+ *out_type = type;
Can't you get rid of the whole switch statement and just do:
*out_type = intspec[1];
That wouldn't catch erroneous values like 6.
[...]
+static int octeon_irq_ciu_map(struct irq_domain *d,
+ unsigned int virq, irq_hw_number_t hw)
+{
+ unsigned int line = hw 6;
+ unsigned int bit = hw 63;
+
+ if (virq= 256)
+ return -EINVAL;
Drop this. You should not care what the virq numbers are.
I care that they don't overflow the width of octeon_irq_ciu_to_irq (a u8).
So really I want to say:
if (virq = (1 sizeof (octeon_irq_ciu_to_irq[0][0]))) {
WARN(...);
return -EINVAL;
}
I need a map external to any one irq_domain. The irq handling code
handles sources that come from two separate irq_domains, as well as irqs
that are not part of any domain.
Thanks for looking at this again, I will re-spin the patch,
David Daney
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 3/4] MIPS: Octeon: Add device tree source files.
On 03/26/2012 07:38 PM, Rob Herring wrote:
On 03/26/2012 02:31 PM, David Daney wrote:
From: David Daneydavid.da...@cavium.com
[...]
+++ b/Documentation/devicetree/bindings/gpio/cavium-octeon-gpio.txt
@@ -0,0 +1,48 @@
+* General Purpose Input Output (GPIO) bus.
+
+Properties:
+- compatible: cavium,octeon-3860-gpio
+
+ Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
+
+- reg: The base address of the GPIO unit's register bank.
+
+- gpio-controller: This is a GPIO controller.
+
+- #gpio-cells: Must be2. The first cell is the GPIO pin.
+
+- interrupt-controller: The GPIO controller is also an interrupt
+ controller, any of its pins may be configured as an interrupt
+ source.
+
+- #interrupt-cells: Must be2. The first cell is the GPIO pin
+ connected to the interrupt source. The second cell is the interrupt
+ triggering protocol and may have one of four values:
+ 1 - edge triggered on the rising edge.
+ 2 - edge triggered on the falling edge
+ 4 - level triggered active high.
+ 8 - level triggered active low.
+
+- interrupts: Interrupt routing for pin 0. The remaining pins are
+ also routed, but in a manner that can be derived from the pin0
+ routing, so they are not specified.
+
+Example:
+
+ gpio-controller@107000800 {
+ #gpio-cells =2;
+ compatible = cavium,octeon-3860-gpio;
+ reg =0x10700 0x0800 0x0 0x100;
+ gpio-controller;
+ /* Interrupts are specified by two parts:
+* 1) GPIO pin number (0..15)
+* 2) Triggering (1 - edge rising
+*2 - edge falling
+*4 - level active high
+*8 - level active low)
+*/
+ interrupt-controller;
+ #interrupt-cells =2;
+ /* The GPIO pin connect to 16 consecutive CUI bits */
+ interrupts =0 16;
I think this should really be:
interrupts =0 16 0 17 0 18 0 19 ... 0 31;
Yes, probably it should be, I will try it. I was having trouble getting
the dtc to accept it when I originally came up with the binding. I will
try again.
[...]
diff --git a/Documentation/devicetree/bindings/mips/cavium/bootbus.txt
b/Documentation/devicetree/bindings/mips/cavium/bootbus.txt
new file mode 100644
index 000..6581478
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/cavium/bootbus.txt
@@ -0,0 +1,126 @@
+* Boot Bus
+
+The Octeon Boot Bus is a configurable parallel bus with 8 chip
+selects. Each chip select is independently configurable.
+
+Properties:
+- compatible: cavium,octeon-3860-bootbus
+
+ Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
+
+- reg: The base address of the Boot Bus' register bank.
+
+- #address-cells: Must be2. The first cell is the chip select
+ within the bootbus. The second cell is the offset from the chip select.
+
+- #size-cells: Must be1.
+
+- ranges: There must be one one triplet of (child-bus-address,
+ parent-bus-address, length) for each active chip select. If the
+ length element for any triplet is zero, the chip select is disabled,
+ making it inactive.
+
+The configuration parameters for each chip select are stored in child
+nodes.
+
+Configuration Properties:
+- compatible: cavium,octeon-3860-bootbus-config
+
+- cavium,cs-index: A single cell indicating the chip select that
+ corresponds to this configuration.
+
+- cavium,t-adr: A cell specifying the ADR timing (in nS).
Add -ns to these time values.
I would prefer not to. There is already firmware in the field with
these bindings. They were discussed here:
http://www.linux-mips.org/archives/linux-mips/2011-06/msg00338.html
Also there is precedence: Few, if any, of the clock rate and frequency
properties end in '-hz'
[...]
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 3/5] ARM: kirkwood: Allow nand to be configured via. devicetree
Add default configuration for NAND, to be enabled in your board config. Ensure
clock gating is set appropriately when the NAND is enabled.
Acked-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Jamie Lentin j...@lentin.co.uk
---
arch/arm/boot/dts/kirkwood.dtsi | 15 ++-
arch/arm/mach-kirkwood/common.c | 12
2 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index 3474ef8..6b80374 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -5,7 +5,7 @@
ocp@f100 {
compatible = simple-bus;
- ranges = 0 0xf100 0x100;
+ ranges = 0 0xf100 0x400;
#address-cells = 1;
#size-cells = 1;
@@ -32,5 +32,18 @@
reg = 0x10300 0x20;
interrupts = 53;
};
+
+ nand@300 {
+ #address-cells = 1;
+ #size-cells = 1;
+ cle = 0;
+ ale = 1;
+ bank-width = 8;
+ compatible = mrvl,orion-nand;
+ reg = 0x300 0x400;
+ chip-delay = 25;
+ /* set partition map and/or chip-delay in board dts */
+ status = disabled;
+ };
};
};
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index a02cae8..3ad0373 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -15,6 +15,7 @@
#include linux/ata_platform.h
#include linux/mtd/nand.h
#include linux/dma-mapping.h
+#include linux/of.h
#include net/dsa.h
#include asm/page.h
#include asm/timex.h
@@ -482,6 +483,9 @@ static int __init kirkwood_clock_gate(void)
unsigned int curr = readl(CLOCK_GATING_CTRL);
u32 dev, rev;
+#ifdef CONFIG_OF
+ struct device_node *np;
+#endif
kirkwood_pcie_id(dev, rev);
printk(KERN_DEBUG Gating clock of unused units\n);
printk(KERN_DEBUG before: 0x%08x\n, curr);
@@ -489,6 +493,14 @@ static int __init kirkwood_clock_gate(void)
/* Make sure those units are accessible */
writel(curr | CGC_SATA0 | CGC_SATA1 | CGC_PEX0 | CGC_PEX1,
CLOCK_GATING_CTRL);
+#ifdef CONFIG_OF
+ np = of_find_compatible_node(NULL, NULL, mrvl,orion-nand);
+ if (np of_device_is_available(np)) {
+ kirkwood_clk_ctrl |= CGC_RUNIT;
+ of_node_put(np);
+ }
+#endif
+
/* For SATA: first shutdown the phy */
if (!(kirkwood_clk_ctrl CGC_SATA0)) {
/* Disable PLL and IVREF */
--
1.7.9.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 2/5] mtd: Add orion_nand devicetree bindings
Allow a NAND chip using the orion_nand driver to be described using devicetree.
Acked-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Jamie Lentin j...@lentin.co.uk
---
.../devicetree/bindings/mtd/orion-nand.txt | 46
drivers/mtd/nand/orion_nand.c | 35 ++-
2 files changed, 79 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/orion-nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/orion-nand.txt
b/Documentation/devicetree/bindings/mtd/orion-nand.txt
new file mode 100644
index 000..22c7438
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/orion-nand.txt
@@ -0,0 +1,46 @@
+NAND support for Marvell Orion SoC platforms
+
+Required properties:
+- compatible : mrvl,orion-nand.
+- reg : Base physical address of the NAND and length of memory mapped
+ region
+
+Optional properties:
+- cle :
+- ale :
+- bank-width :
+- chip-delay :
+
+Examples:
+
+nand@f400 {
+ #address-cells = 1;
+ #size-cells = 1;
+ cle = 0;
+ ale = 1;
+ bank-width = 8;
+ chip-delay = 25;
+ compatible = mrvl,orion-nand;
+ reg = 0xf400 0x400;
+
+ partition@0 {
+ label = u-boot;
+ reg = 0x000 0x10;
+ read-only;
+ };
+
+ partition@10 {
+ label = uImage;
+ reg = 0x010 0x20;
+ };
+
+ partition@30 {
+ label = dtb;
+ reg = 0x030 0x10;
+ };
+
+ partition@40 {
+ label = root;
+ reg = 0x040 0x7d0;
+ };
+};
diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
index 29f505a..3b7c82f 100644
--- a/drivers/mtd/nand/orion_nand.c
+++ b/drivers/mtd/nand/orion_nand.c
@@ -13,6 +13,7 @@
#include linux/slab.h
#include linux/module.h
#include linux/platform_device.h
+#include linux/of.h
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
@@ -74,11 +75,13 @@ static void orion_nand_read_buf(struct mtd_info *mtd,
uint8_t *buf, int len)
static int __init orion_nand_probe(struct platform_device *pdev)
{
struct mtd_info *mtd;
+ struct mtd_part_parser_data ppdata = {};
struct nand_chip *nc;
struct orion_nand_data *board;
struct resource *res;
void __iomem *io_base;
int ret = 0;
+ u32 val = 0;
nc = kzalloc(sizeof(struct nand_chip) + sizeof(struct mtd_info),
GFP_KERNEL);
if (!nc) {
@@ -101,7 +104,26 @@ static int __init orion_nand_probe(struct platform_device
*pdev)
goto no_res;
}
- board = pdev-dev.platform_data;
+ if (pdev-dev.of_node) {
+ board = devm_kzalloc(pdev-dev, sizeof(struct orion_nand_data),
+ GFP_KERNEL);
+ if (!board) {
+ printk(KERN_ERR orion_nand: failed to allocate board
structure.\n);
+ ret = -ENOMEM;
+ goto no_res;
+ }
+ if (!of_property_read_u32(pdev-dev.of_node, cle, val))
+ board-cle = (u8)val;
+ if (!of_property_read_u32(pdev-dev.of_node, ale, val))
+ board-ale = (u8)val;
+ if (!of_property_read_u32(pdev-dev.of_node,
+ bank-width, val))
+ board-width = (u8)val;
+ if (!of_property_read_u32(pdev-dev.of_node,
+ chip-delay, val))
+ board-chip_delay = (u8)val;
+ } else
+ board = pdev-dev.platform_data;
mtd-priv = nc;
mtd-owner = THIS_MODULE;
@@ -129,7 +151,8 @@ static int __init orion_nand_probe(struct platform_device
*pdev)
}
mtd-name = orion_nand;
- ret = mtd_device_parse_register(mtd, NULL, 0,
+ ppdata.of_node = pdev-dev.of_node;
+ ret = mtd_device_parse_register(mtd, NULL, ppdata,
board-parts, board-nr_parts);
if (ret) {
nand_release(mtd);
@@ -161,11 +184,19 @@ static int __devexit orion_nand_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static struct of_device_id orion_nand_of_match_table[] = {
+ { .compatible = mrvl,orion-nand, },
+ {},
+};
+#endif
+
static struct platform_driver orion_nand_driver = {
.remove = __devexit_p(orion_nand_remove),
.driver = {
.name = orion_nand,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(orion_nand_of_match_table),
},
};
--
1.7.9.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 0/5] Add support for DNS-320 and DNS-325 using devicetree
Thanks again to Arnd, Jason Scott. The differences here are fairly minor. Apart from documentation, I'm guessing that the changes aren't significant enough to revoke Acked-by, please flame me if I'm wrong! Changes since v2: * Split patches further, separating orion_nand and kirkwood changes * dts renames: bank-width, not width. okay, not ok * Separate documentation out into separate patch, add references to partition.txt to all mtd bindings. Changes since v1: * Rebase against kirkwood_dt_for_3.4, removing premature devicetree ports. * Move additions into a separate board-dnskw.c. It could be separated further into a board-dns320.c and board-dns325.c but it probably isn't worth it. * s/marvell,/mrvl,/g * Include an example dtb partition in documentation * Copy structure of serial nodes to allow common options for NAND to be set in kirkwood.dtsi * Simplifications in orion-nand.c Jamie Lentin (5): ARM: kirkwood: Basic support for DNS-320 and DNS-325 mtd: Add orion_nand devicetree bindings ARM: kirkwood: Allow nand to be configured via. devicetree ARM: kirkwood: Define DNS-320/DNS-325 NAND in fdt mtd: Move fdt partition documentation to a seperate file .../devicetree/bindings/mtd/arm-versatile.txt |4 +- .../devicetree/bindings/mtd/atmel-dataflash.txt|3 + .../devicetree/bindings/mtd/fsl-upm-nand.txt |4 + .../devicetree/bindings/mtd/gpio-control-nand.txt |3 + .../devicetree/bindings/mtd/mtd-physmap.txt| 23 +-- .../devicetree/bindings/mtd/orion-nand.txt | 49 .../devicetree/bindings/mtd/partition.txt | 38 +++ arch/arm/boot/dts/kirkwood-dns320.dts | 64 + arch/arm/boot/dts/kirkwood-dns325.dts | 59 + arch/arm/boot/dts/kirkwood.dtsi| 15 +- arch/arm/mach-kirkwood/Kconfig | 23 ++ arch/arm/mach-kirkwood/Makefile|1 + arch/arm/mach-kirkwood/Makefile.boot |2 + arch/arm/mach-kirkwood/board-dnskw.c | 275 arch/arm/mach-kirkwood/board-dt.c |5 + arch/arm/mach-kirkwood/common.c| 12 + arch/arm/mach-kirkwood/common.h|6 + drivers/mtd/nand/orion_nand.c | 35 +++- 18 files changed, 595 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/orion-nand.txt create mode 100644 Documentation/devicetree/bindings/mtd/partition.txt create mode 100644 arch/arm/boot/dts/kirkwood-dns320.dts create mode 100644 arch/arm/boot/dts/kirkwood-dns325.dts create mode 100644 arch/arm/mach-kirkwood/board-dnskw.c -- 1.7.9.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3 4/5] ARM: kirkwood: Define DNS-320/DNS-325 NAND in fdt
Use devicetree to define NAND partitions. Use D-link partition scheme by
default, to be vaguely compatible with their userland.
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: Jason Cooper ja...@lakedaemon.net
Signed-off-by: Jamie Lentin j...@lentin.co.uk
---
arch/arm/boot/dts/kirkwood-dns320.dts | 35 +
arch/arm/boot/dts/kirkwood-dns325.dts | 35 +
arch/arm/mach-kirkwood/board-dnskw.c | 31 -
3 files changed, 70 insertions(+), 31 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-dns320.dts
b/arch/arm/boot/dts/kirkwood-dns320.dts
index 78c834f..dc09a73 100644
--- a/arch/arm/boot/dts/kirkwood-dns320.dts
+++ b/arch/arm/boot/dts/kirkwood-dns320.dts
@@ -25,5 +25,40 @@
clock-frequency = 16667;
status = okay;
};
+
+ nand@300 {
+ status = okay;
+
+ partition@0 {
+ label = u-boot;
+ reg = 0x000 0x10;
+ read-only;
+ };
+
+ partition@10 {
+ label = uImage;
+ reg = 0x010 0x50;
+ };
+
+ partition@60 {
+ label = ramdisk;
+ reg = 0x060 0x50;
+ };
+
+ partition@b0 {
+ label = image;
+ reg = 0x0b0 0x660;
+ };
+
+ partition@710 {
+ label = mini firmware;
+ reg = 0x710 0xa0;
+ };
+
+ partition@7b0 {
+ label = config;
+ reg = 0x7b0 0x50;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/kirkwood-dns325.dts
b/arch/arm/boot/dts/kirkwood-dns325.dts
index 23241ab..c2a5562 100644
--- a/arch/arm/boot/dts/kirkwood-dns325.dts
+++ b/arch/arm/boot/dts/kirkwood-dns325.dts
@@ -20,5 +20,40 @@
clock-frequency = 2;
status = okay;
};
+
+ nand@300 {
+ status = okay;
+
+ partition@0 {
+ label = u-boot;
+ reg = 0x000 0x10;
+ read-only;
+ };
+
+ partition@10 {
+ label = uImage;
+ reg = 0x010 0x50;
+ };
+
+ partition@60 {
+ label = ramdisk;
+ reg = 0x060 0x50;
+ };
+
+ partition@b0 {
+ label = image;
+ reg = 0x0b0 0x660;
+ };
+
+ partition@710 {
+ label = mini firmware;
+ reg = 0x710 0xa0;
+ };
+
+ partition@7b0 {
+ label = config;
+ reg = 0x7b0 0x50;
+ };
+ };
};
};
diff --git a/arch/arm/mach-kirkwood/board-dnskw.c
b/arch/arm/mach-kirkwood/board-dnskw.c
index 7cb7f6a..dc4e80a 100644
--- a/arch/arm/mach-kirkwood/board-dnskw.c
+++ b/arch/arm/mach-kirkwood/board-dnskw.c
@@ -23,7 +23,6 @@
#include linux/gpio_keys.h
#include linux/gpio-fan.h
#include linux/leds.h
-#include linux/mtd/physmap.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -32,35 +31,6 @@
#include common.h
#include mpp.h
-static struct mtd_partition dnskw_nand_parts[] = {
- {
- .name = u-boot,
- .offset = 0,
- .size = SZ_1M,
- .mask_flags = MTD_WRITEABLE
- }, {
- .name = uImage,
- .offset = MTDPART_OFS_NXTBLK,
- .size = 5 * SZ_1M
- }, {
- .name = ramdisk,
- .offset = MTDPART_OFS_NXTBLK,
- .size = 5 * SZ_1M
- }, {
- .name = image,
- .offset = MTDPART_OFS_NXTBLK,
- .size = 102 * SZ_1M
- }, {
- .name = mini firmware,
- .offset = MTDPART_OFS_NXTBLK,
- .size = 10 * SZ_1M
-
[PATCH V3 1/5] ARM: kirkwood: Basic support for DNS-320 and DNS-325
Add support for the DNS-320 and DNS-325. Describe as much as currently possible
in the devicetree files, create a board-dnskw.c for everything else.
Use IEEE-compliant okay, rather than ok
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: Jason Cooper ja...@lakedaemon.net
Signed-off-by: Jamie Lentin j...@lentin.co.uk
---
arch/arm/boot/dts/kirkwood-dns320.dts | 29 +++
arch/arm/boot/dts/kirkwood-dns325.dts | 24 +++
arch/arm/mach-kirkwood/Kconfig| 23 +++
arch/arm/mach-kirkwood/Makefile |1 +
arch/arm/mach-kirkwood/Makefile.boot |2 +
arch/arm/mach-kirkwood/board-dnskw.c | 306 +
arch/arm/mach-kirkwood/board-dt.c |5 +
arch/arm/mach-kirkwood/common.h |6 +
8 files changed, 396 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/kirkwood-dns320.dts
create mode 100644 arch/arm/boot/dts/kirkwood-dns325.dts
create mode 100644 arch/arm/mach-kirkwood/board-dnskw.c
diff --git a/arch/arm/boot/dts/kirkwood-dns320.dts
b/arch/arm/boot/dts/kirkwood-dns320.dts
new file mode 100644
index 000..78c834f
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-dns320.dts
@@ -0,0 +1,29 @@
+/dts-v1/;
+
+/include/ kirkwood.dtsi
+
+/ {
+ model = D-Link DNS-320 NAS (Rev A1);
+ compatible = dlink,dns-320-a1, dlink,dns-320, dlink,dns-kirkwood,
mrvl,kirkwood-88f6281, mrvl,kirkwood;
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x800;
+ };
+
+ chosen {
+ bootargs = console=ttyS0,115200n8 earlyprintk;
+ };
+
+ ocp@f100 {
+ serial@12000 {
+ clock-frequency = 16667;
+ status = okay;
+ };
+
+ serial@12100 {
+ clock-frequency = 16667;
+ status = okay;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-dns325.dts
b/arch/arm/boot/dts/kirkwood-dns325.dts
new file mode 100644
index 000..23241ab
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-dns325.dts
@@ -0,0 +1,24 @@
+/dts-v1/;
+
+/include/ kirkwood.dtsi
+
+/ {
+ model = D-Link DNS-325 NAS (Rev A1);
+ compatible = dlink,dns-325-a1, dlink,dns-325, dlink,dns-kirkwood,
mrvl,kirkwood-88f6281, mrvl,kirkwood;
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x1000;
+ };
+
+ chosen {
+ bootargs = console=ttyS0,115200n8 earlyprintk;
+ };
+
+ ocp@f100 {
+ serial@12000 {
+ clock-frequency = 2;
+ status = okay;
+ };
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 90ceab7..d594b6e 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -58,6 +58,29 @@ config MACH_DREAMPLUG_DT
Say 'Y' here if you want your kernel to support the
Marvell DreamPlug (Flattened Device Tree).
+config MACH_DNSKW_DT
+bool
+
+config MACH_DNS320_DT
+ bool D-Link DNS-320 (Flattened Device Tree)
+ select ARCH_KIRKWOOD_DT
+ select MACH_DNSKW_DT
+ select CONFIG_MTD_OF_PARTS
+ select CONFIG_SERIAL_OF_PLATFORM
+ help
+ Say 'Y' here if you want your kernel to support the
+ D-Link DNS-320 NAS, using Flattened Device Tree.
+
+config MACH_DNS325_DT
+ bool D-Link DNS-325 (Flattened Device Tree)
+ select ARCH_KIRKWOOD_DT
+ select MACH_DNSKW_DT
+ select CONFIG_MTD_OF_PARTS
+ select CONFIG_SERIAL_OF_PLATFORM
+ help
+ Say 'Y' here if you want your kernel to support the
+ D-Link DNS-325 NAS, using Flattened Device Tree.
+
config MACH_TS219
bool QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and
TS-219P+ Turbo NAS
help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index e299a95..b092af5 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_MACH_T5325) += t5325-setup.o
obj-$(CONFIG_CPU_IDLE) += cpuidle.o
obj-$(CONFIG_ARCH_KIRKWOOD_DT) += board-dt.o
obj-$(CONFIG_MACH_DREAMPLUG_DT)+= board-dreamplug.o
+obj-$(CONFIG_MACH_DNSKW_DT)+= board-dnskw.o
diff --git a/arch/arm/mach-kirkwood/Makefile.boot
b/arch/arm/mach-kirkwood/Makefile.boot
index 16f9385..9c5e45f 100644
--- a/arch/arm/mach-kirkwood/Makefile.boot
+++ b/arch/arm/mach-kirkwood/Makefile.boot
@@ -3,3 +3,5 @@ params_phys-y := 0x0100
initrd_phys-y := 0x0080
dtb-$(CONFIG_MACH_DREAMPLUG_DT) += kirkwood-dreamplug.dtb
+dtb-$(CONFIG_MACH_DNS320_DT) += kirkwood-dns320.dtb
+dtb-$(CONFIG_MACH_DNS325_DT) += kirkwood-dns325.dtb
diff --git a/arch/arm/mach-kirkwood/board-dnskw.c
b/arch/arm/mach-kirkwood/board-dnskw.c
new file mode 100644
index 000..7cb7f6a
---
Re: [PATCH v7 2/4] MIPS: Octeon: Setup irq_domains for interrupts.
On 03/27/2012 01:24 PM, David Daney wrote:
On 03/26/2012 06:56 PM, Rob Herring wrote:
On 03/26/2012 02:31 PM, David Daney wrote:
From: David Daneydavid.da...@cavium.com
[...]
+static bool octeon_irq_ciu_is_edge(unsigned int line, unsigned int bit)
+{
+bool edge = false;
+
+if (line == 0)
+switch (bit) {
+case 48 ... 49: /* GMX DRP */
+case 50: /* IPD_DRP */
+case 52 ... 55: /* Timers */
+case 58: /* MPI */
+edge = true;
+break;
+default:
+break;
+}
+else /* line == 1 */
+switch (bit) {
+case 47: /* PTP */
+edge = true;
+break;
+default:
+break;
+}
+return edge;
Moving in the right direction, but I still don't get why this is not in
the CIU binding as a 3rd cell?
There are a several reasons, in no particular order they are:
o There is no 3rd cell. The bindings were discussed with Grant here:
http://www.linux-mips.org/archives/linux-mips/2011-05/msg00355.html
Then add one.
o The edge/level thing cannot be changed, and the irq lines don't leave
the SOC, so hard coding it is possible.
Right, but DT describes h/w connections and this is an aspect of the
connection. This may be fixed for the SOC, but it's not fixed for the
CIU (i.e. could change in future chips), right?
There's 2 reasons why you would not put this into DTS:
- All irq lines' trigger type are the same, fixed and known.
- You can read a register to tell you the trigger type.
Even if it's not going to change ever, it's still worth putting into the
DTS as it is well suited for holding that data and it is just data.
+}
+
+struct octeon_irq_gpio_domain_data {
+unsigned int base_hwirq;
+};
+
+static int octeon_irq_gpio_xlat(struct irq_domain *d,
+struct device_node *node,
+const u32 *intspec,
+unsigned int intsize,
+unsigned long *out_hwirq,
+unsigned int *out_type)
+{
+unsigned int type;
+unsigned int pin;
+unsigned int trigger;
+bool set_edge_handler = false;
+struct octeon_irq_gpio_domain_data *gpiod;
+
+if (d-of_node != node)
+return -EINVAL;
+
+if (intsize 2)
+return -EINVAL;
+
+pin = intspec[0];
+if (pin= 16)
+return -EINVAL;
+
+trigger = intspec[1];
+
+switch (trigger) {
+case 1:
+type = IRQ_TYPE_EDGE_RISING;
+set_edge_handler = true;
This is never used.
Right, it was leftover from the previous version.
+break;
+case 2:
+type = IRQ_TYPE_EDGE_FALLING;
+set_edge_handler = true;
+break;
+case 4:
+type = IRQ_TYPE_LEVEL_HIGH;
+break;
+case 8:
+type = IRQ_TYPE_LEVEL_LOW;
+break;
+default:
+pr_err(Error: (%s) Invalid irq trigger specification: %x\n,
+ node-name,
+ trigger);
+type = IRQ_TYPE_LEVEL_LOW;
+break;
+}
+*out_type = type;
Can't you get rid of the whole switch statement and just do:
*out_type = intspec[1];
That wouldn't catch erroneous values like 6.
if (!x || fls(x) != ffs(x))
// ERROR
[...]
+static int octeon_irq_ciu_map(struct irq_domain *d,
+ unsigned int virq, irq_hw_number_t hw)
+{
+unsigned int line = hw 6;
+unsigned int bit = hw 63;
+
+if (virq= 256)
+return -EINVAL;
Drop this. You should not care what the virq numbers are.
I care that they don't overflow the width of octeon_irq_ciu_to_irq (a u8).
So really I want to say:
if (virq = (1 sizeof (octeon_irq_ciu_to_irq[0][0]))) {
WARN(...);
return -EINVAL;
}
I need a map external to any one irq_domain. The irq handling code
handles sources that come from two separate irq_domains, as well as irqs
that are not part of any domain.
Okay, but ultimately this needs to go. The irqdomain provides no
guarantee of irq numbers assigned.
Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 2/4] MIPS: Octeon: Setup irq_domains for interrupts.
On 03/27/2012 03:05 PM, Rob Herring wrote:
On 03/27/2012 01:24 PM, David Daney wrote:
On 03/26/2012 06:56 PM, Rob Herring wrote:
On 03/26/2012 02:31 PM, David Daney wrote:
From: David Daneydavid.da...@cavium.com
[...]
+static bool octeon_irq_ciu_is_edge(unsigned int line, unsigned int bit)
+{
+bool edge = false;
+
+if (line == 0)
+switch (bit) {
+case 48 ... 49: /* GMX DRP */
+case 50: /* IPD_DRP */
+case 52 ... 55: /* Timers */
+case 58: /* MPI */
+edge = true;
+break;
+default:
+break;
+}
+else /* line == 1 */
+switch (bit) {
+case 47: /* PTP */
+edge = true;
+break;
+default:
+break;
+}
+return edge;
Moving in the right direction, but I still don't get why this is not in
the CIU binding as a 3rd cell?
There are a several reasons, in no particular order they are:
o There is no 3rd cell. The bindings were discussed with Grant here:
http://www.linux-mips.org/archives/linux-mips/2011-05/msg00355.html
Then add one.
I can't. The dtb is already programmed into the bootloader ROMs,
changing the kernel code will not change that. It is fait accompli.
o The edge/level thing cannot be changed, and the irq lines don't leave
the SOC, so hard coding it is possible.
Right, but DT describes h/w connections and this is an aspect of the
connection. This may be fixed for the SOC, but it's not fixed for the
CIU (i.e. could change in future chips), right?
In theory yes. However:
1) The chip designers will not change it.
2) There will likely be no more designs with either CIU or CIU2, so we
know what all the different possibilities are today.
When CIU3 is deployed, we will use the lessons we have learned to do
things the Right Way.
There's 2 reasons why you would not put this into DTS:
- All irq lines' trigger type are the same, fixed and known.
- You can read a register to tell you the trigger type.
Even if it's not going to change ever, it's still worth putting into the
DTS as it is well suited for holding that data and it is just data.
Agreed that it could be in the DTS, and retrospect it probably should
have been put in the DTS, but it wasn't. So I think what we have now is
a workable solution, and has the added attraction of working with
already deployed boards.
David Daney
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V2] dtc: Basic integer expressions
Written by David Gibson da...@gibson.dropbear.id.au. Additions by me:
* Ported to ToT dtc.
* Renamed cell to integer throughout.
* Implemented value range checks.
* Allow L/UL/LL/ULL suffix on literals.
* Enabled the commented test.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
v2:
* s/cell/integer/ throughout.
* Allow signed-extended values to pass the overall cell range check.
* Allow L/UL/LL/ULL suffix on literals. This is purely for compatibility
with C, and has no effect on dtc's processing.
* Enabled the 3 disabled tests.
I'm not sure if the literal suffix handling is hacky or not...
dtc-lexer.l | 11 +++-
dtc-parser.y| 131 ---
tests/Makefile.tests|3 +-
tests/integer-expressions.c | 117 ++
tests/run_tests.sh |5 ++
5 files changed, 256 insertions(+), 11 deletions(-)
create mode 100644 tests/integer-expressions.c
diff --git a/dtc-lexer.l b/dtc-lexer.l
index 73d190c..0dbbbd5 100644
--- a/dtc-lexer.l
+++ b/dtc-lexer.l
@@ -110,7 +110,7 @@ static int pop_input_file(void);
return DT_LABEL;
}
-V1[0-9]+|0[xX][0-9a-fA-F]+ {
+V1([0-9]+|0[xX][0-9a-fA-F]+)(L|UL|LL|ULL)? {
yylval.literal = xstrdup(yytext);
DPRINT(Literal: '%s'\n, yylval.literal);
return DT_LITERAL;
@@ -164,6 +164,15 @@ static int pop_input_file(void);
*{COMMENT}+ /* eat C-style comments */
*{LINECOMMENT}+ /* eat C++-style comments */
+*{ return DT_LSHIFT; };
+*{ return DT_RSHIFT; };
+*={ return DT_LE; };
+*={ return DT_GE; };
+*=={ return DT_EQ; };
+*!={ return DT_NE; };
+*{ return DT_AND; };
+*||{ return DT_OR; };
+
*. {
DPRINT(Char: %c (\\x%02x)\n, yytext[0],
(unsigned)yytext[0]);
diff --git a/dtc-parser.y b/dtc-parser.y
index 348616b..19db90e 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -56,10 +56,12 @@ static unsigned char eval_char_literal(const char *s);
struct node *node;
struct node *nodelist;
struct reserve_info *re;
+ uint64_t integer;
}
%token DT_V1
%token DT_MEMRESERVE
+%token DT_LSHIFT DT_RSHIFT DT_LE DT_GE DT_EQ DT_NE DT_AND DT_OR
%token DT_BITS
%token propnodename DT_PROPNODENAME
%token literal DT_LITERAL
@@ -86,6 +88,21 @@ static unsigned char eval_char_literal(const char *s);
%type node subnode
%type nodelist subnodes
+%type integer integer_prim
+%type integer integer_unary
+%type integer integer_mul
+%type integer integer_add
+%type integer integer_shift
+%type integer integer_rela
+%type integer integer_eq
+%type integer integer_bitand
+%type integer integer_bitxor
+%type integer integer_bitor
+%type integer integer_and
+%type integer integer_or
+%type integer integer_trinary
+%type integer integer_expr
+
%%
sourcefile:
@@ -267,17 +284,17 @@ arrayprefix:
$$.data = empty_data;
$$.bits = 32;
}
- | arrayprefix DT_LITERAL
- {
- uint64_t val = eval_literal($2, 0, $1.bits);
-
- $$.data = data_append_integer($1.data, val, $1.bits);
- }
- | arrayprefix DT_CHAR_LITERAL
+ | arrayprefix integer_prim
{
- uint64_t val = eval_char_literal($2);
+ if ($1.bits 64) {
+ uint64_t mask = (1ULL $1.bits) - 1;
+ if (($2 mask) (($2 | mask) != -1ULL))
+ print_error(
+ integer value out of range
+ %016lx (%d bits), $1.bits);
+ }
- $$.data = data_append_integer($1.data, val, $1.bits);
+ $$.data = data_append_integer($1.data, $2, $1.bits);
}
| arrayprefix DT_REF
{
@@ -299,6 +316,95 @@ arrayprefix:
}
;
+integer_prim:
+ DT_LITERAL
+ {
+ $$ = eval_literal($1, 0, 64);
+ }
+ | DT_CHAR_LITERAL
+ {
+ $$ = eval_char_literal($1);
+ }
+ | '(' integer_expr ')'
+ {
+ $$ = $2;
+ }
+ ;
+
+integer_expr:
+ integer_trinary
+ ;
+
+integer_trinary:
+ integer_or
+ | integer_or '?' integer_expr ':' integer_trinary { $$ = $1 ? $3 : $5 }
+ ;
+
+integer_or:
+ integer_and
+ | integer_or DT_OR integer_and { $$ = $1 || $3 };
+ ;
+
+integer_and:
+ integer_bitor
+ | integer_and DT_AND integer_bitor
[PATCH] dtc: check for duplicate labels when they are defined
Currently, the DT is checked for duplicate labels after the entire DT has
been parsed. However, once parts of the DT can be deleted, some entities
with labels may have been deleted by this time, thus making those labels
invisible to the duplicate label check, which can then lead to false
negatives.
Instead, maintain a list of all known labels, from which entries are
never deleted, and check against this list for duplicates when adding
labels.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
This patch should be applied before my previously posted dtc: Add
ability to delete nodes and properties. I believe it addresses David's
concerns with that patch re: the assumption that labels are immutable.
checks.c | 58
data.c |3 ++
dtc.h |1 +
livetree.c | 18 ---
tests/run_tests.sh | 12 +-
5 files changed, 24 insertions(+), 68 deletions(-)
diff --git a/checks.c b/checks.c
index a662a00..a625e29 100644
--- a/checks.c
+++ b/checks.c
@@ -278,62 +278,6 @@ static void check_property_name_chars(struct check *c,
struct node *dt,
}
PROP_CHECK(property_name_chars, PROPNODECHARS, ERROR);
-#define DESCLABEL_FMT %s%s%s%s%s
-#define DESCLABEL_ARGS(node,prop,mark) \
- ((mark) ? value of : ),\
- ((prop) ? ' : ), \
- ((prop) ? (prop)-name : ), \
- ((prop) ? ' in : ), (node)-fullpath
-
-static void check_duplicate_label(struct check *c, struct node *dt,
- const char *label, struct node *node,
- struct property *prop, struct marker *mark)
-{
- struct node *othernode = NULL;
- struct property *otherprop = NULL;
- struct marker *othermark = NULL;
-
- othernode = get_node_by_label(dt, label);
-
- if (!othernode)
- otherprop = get_property_by_label(dt, label, othernode);
- if (!othernode)
- othermark = get_marker_label(dt, label, othernode,
- otherprop);
-
- if (!othernode)
- return;
-
- if ((othernode != node) || (otherprop != prop) || (othermark != mark))
- FAIL(c, Duplicate label '%s' on DESCLABEL_FMT
- and DESCLABEL_FMT,
-label, DESCLABEL_ARGS(node, prop, mark),
-DESCLABEL_ARGS(othernode, otherprop, othermark));
-}
-
-static void check_duplicate_label_node(struct check *c, struct node *dt,
- struct node *node)
-{
- struct label *l;
-
- for_each_label(node-labels, l)
- check_duplicate_label(c, dt, l-label, node, NULL, NULL);
-}
-static void check_duplicate_label_prop(struct check *c, struct node *dt,
- struct node *node, struct property *prop)
-{
- struct marker *m = prop-val.markers;
- struct label *l;
-
- for_each_label(prop-labels, l)
- check_duplicate_label(c, dt, l-label, node, prop, NULL);
-
- for_each_marker_of_type(m, LABEL)
- check_duplicate_label(c, dt, m-ref, node, prop, m);
-}
-CHECK(duplicate_label, NULL, check_duplicate_label_node,
- check_duplicate_label_prop, NULL, ERROR);
-
static void check_explicit_phandles(struct check *c, struct node *root,
struct node *node, struct property *prop)
{
@@ -630,8 +574,6 @@ static struct check *check_table[] = {
node_name_chars, node_name_format, property_name_chars,
name_is_string, name_properties,
- duplicate_label,
-
explicit_phandles,
phandle_references, path_references,
diff --git a/data.c b/data.c
index 4a40c5b..16091c1 100644
--- a/data.c
+++ b/data.c
@@ -241,6 +241,9 @@ struct data data_add_marker(struct data d, enum markertype
type, char *ref)
{
struct marker *m;
+ if (type == LABEL)
+ add_label(NULL, ref);
+
m = xmalloc(sizeof(*m));
m-offset = d.len;
m-type = type;
diff --git a/dtc.h b/dtc.h
index 7b4c65b..bcd5913 100644
--- a/dtc.h
+++ b/dtc.h
@@ -129,6 +129,7 @@ int data_is_one_string(struct data d);
struct label {
char *label;
struct label *next;
+ struct label *all_next;
};
struct property {
diff --git a/livetree.c b/livetree.c
index c9209d5..f12f2c9 100644
--- a/livetree.c
+++ b/livetree.c
@@ -24,19 +24,29 @@
* Tree building functions
*/
+struct label *all_labels;
+
+extern void print_error(char const *fmt, ...);
+
void add_label(struct label **labels, char *label)
{
struct label *new;
/* Make sure the label isn't already there */
- for_each_label(*labels, new)
+ for_each_label(all_labels, new)
if (streq(new-label, label))
- return;
+ print_error(Duplicate label '%s', label);
new =
Re: [PATCH] of/irq: add empty irq_of_parse_and_map() for non-dt builds
On Sun, 25 Mar 2012 20:26:15 +0530, Thomas Abraham thomas.abra...@linaro.org wrote: On 25 March 2012 06:12, Grant Likely grant.lik...@secretlab.ca wrote: On Sat, 24 Mar 2012 08:12:39 -0500, Rob Herring robherri...@gmail.com wrote: On 03/24/2012 04:27 AM, Thomas Abraham wrote: Add a empty irq_of_parse_and_map() that returns 0 for non-dt builds and avoid having #ifdef CONFIG_OF around all calls to irq_of_parse_and_map(). Suggested-by: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- Acked-by: Rob Herring rob.herr...@calxeda.com Go ahead and merge with the rest of your series. Actually, it's not quite fully baked; the forward declaration of irq_of_parse_and_map() needs to be moved under the #if defined(CONFIG_OF_IRQ) block (just move the #if statement up 7 lines). After doing that you can add my acked-by and merge it with the rest of your series. Â There is no sense merging it through my tree when you are the only user depending on it. Acked-by: Grant Likely grant.lik...@secretlab.ca Thanks. I will do that change which you have suggested and take it through the Samsung tree. But I was thinking that if it goes through your tree, there would be less chances of a merge conflict in include/linux/of_irq.h, a file that might see updates from other sources. Hmmm... is this going to be merged for v3.4 or v3.5? If it is v3.5, then yes it probably does need to go through my tree since there may be others that need to pull it into their trees. I was thinking that you needed this immediately. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 7/7] sm501: restore big-endian operation.
On SH, as of 37b7a97884ba64bf7d403351ac2a9476ab4f1bba we have to use the
endianess-agnostic I/O accessor functions.
In commit bf5f0019046d596d613caf74722ba4994e153899, Heiko fixed this for 32-bit
PowerPC; my patch now generalizes upon that.
The device is now recognized correctly for both litte-endian and big-endian
sh7785lcr, but I have not tested this any further, as the board is situated in
a remote data center.
Signed-off-by: Thomas Schwinge tho...@codesourcery.com
Cc: Paul Mundt let...@linux-sh.org
Cc: linux...@vger.kernel.org
Cc: Heiko Schocher h...@denx.de
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: linux-fb...@vger.kernel.org
Cc: devicetree-disc...@ozlabs.org
Cc: Ben Dooks b...@simtec.co.uk
Cc: Vincent Sanders vi...@simtec.co.uk
Cc: Randy Dunlap rdun...@xenotime.net
---
include/linux/sm501.h |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/include/linux/sm501.h b/include/linux/sm501.h
index 02fde50..0312e3c 100644
--- a/include/linux/sm501.h
+++ b/include/linux/sm501.h
@@ -173,10 +173,5 @@ struct sm501_platdata {
unsigned int gpio_i2c_nr;
};
-#if defined(CONFIG_PPC32)
-#define smc501_readl(addr) ioread32be((addr))
-#define smc501_writel(val, addr) iowrite32be((val), (addr))
-#else
-#define smc501_readl(addr) readl(addr)
-#define smc501_writel(val, addr) writel(val, addr)
-#endif
+#define smc501_readl(addr) __raw_readl(addr)
+#define smc501_writel(val, addr) __raw_writel(val, addr)
--
1.7.4.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[patch] sata_mv: silence an uninitialized variable warning
Gcc version 4.6.2-12 complains that if we can't find the nr-ports property in of_property_read_u32_array() then n_ports is used uninitialized. Let's set it to zero in that case. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c index ebd0d24..3d8d5c6 100644 --- a/drivers/ata/sata_mv.c +++ b/drivers/ata/sata_mv.c @@ -4026,7 +4026,8 @@ static int mv_platform_probe(struct platform_device *pdev) struct ata_host *host; struct mv_host_priv *hpriv; struct resource *res; - int n_ports, rc; + int n_ports = 0; + int rc; ata_print_version_once(pdev-dev, DRV_VERSION); ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] stmmac: Add device-tree support
On 3/12/2012 4:06 PM, Stefan Roese wrote: Hi Rob, On Monday 12 March 2012 15:34:59 Rob Herring wrote: On 03/12/2012 09:05 AM, Stefan Roese wrote: This patch adds support to configure the STMMAC ethernet driver via device-tree instead of platform_data. Currently, only the properties needed on SPEAr600 are provided. All other properties should be added once needed on other platforms. Signed-off-by: Stefan Roese s...@denx.de Cc: Giuseppe Cavallaro peppe.cavall...@st.com Cc: Viresh Kumar viresh.ku...@st.com --- Documentation/devicetree/bindings/net/stmmac.txt | 38 +++ .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 66 +++- 2 files changed, 103 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/net/stmmac.txt diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt new file mode 100644 index 000..386a47f --- /dev/null +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -0,0 +1,38 @@ +* STMicroelectronics 10/100/1000 Ethernet driver (GMAC) + +Required properties: +- compatible: Should be stm,gmac This is too generic. This should be 1 string per version of h/w. Viresh, Giuseppe, can you please suggest a proper string for the SPEAr600 STMMAC core, including version? 'stm' should be 'st' according to vendor-prefixes.txt. I'm not familiar with devicetree; maybe we should have: stmicro,mac100 stmicro,gmac or: st instead of stmicro if you prefer. in fact, stmmac is for mac100 and gmac devices. Okay. +- reg: Address and length of the register set for the device +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupts: Should contain the STMMAC interrupts +- interrupt-names: Should contain the interrupt names macirq + eth_wake_irq if this interrupt is supported in the interrupts + property You should be able to tell this from the compatible string and number of interrupts. Yes. Currently the driver uses platform_get_irq_byname() to register the irq's. That's why I added these properties. Is there something wrong with using it this way? +- phy-mode: String, operation mode of the PHY interface. + Supported values are: mii, rmii, gmii, rgmii. +- phy-addr: MDIO address of the PHY This is normally probed or the mdio bus is a sub-node of the MAC node. See arch/powerpc/boot/dts/mpc8377_mds.dts for an example. Okay, I'll rework this. + +Optional properties: +- stm,prog-burst-len: Specify the burst length +- stm,has-gmac: Indicates that the controller supports 1000Mbps +- stm,has-pmt: Indicates that the controller supports power management I think these should all be encoded by the compatible string. and should we have all the other flags e.g. tx_coe etc? (see stmmac.txt) Peppe You mean that by defining a specific compatible string (e.g. st,gmac-spear600), these settings are implicitly set? And should therefore be omitted from the dts? Thanks, Stefan -- To unsubscribe from this list: send the line unsubscribe netdev 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] stmmac: Add device-tree support
On 3/12/2012 5:23 PM, Stefan Roese wrote: On Monday 12 March 2012 16:30:37 Giuseppe CAVALLARO wrote: +Required properties: +- compatible: Should be stm,gmac This is too generic. This should be 1 string per version of h/w. Viresh, Giuseppe, can you please suggest a proper string for the SPEAr600 STMMAC core, including version? 'stm' should be 'st' according to vendor-prefixes.txt. I'm not familiar with devicetree; maybe we should have: stmicro,mac100 stmicro,gmac or: st instead of stmicro if you prefer. in fact, stmmac is for mac100 and gmac devices. How about st,spear600-gmac for SPEAr600 then? IIUC, as final result we should have something like this... that sounds quite good to me. ST/ARM SPEAr st,spear600-gmac st,spear1310-gmac ... ST/SH st,stx7108-gmac st,stx7106-gmac st,stx7109-mac- mac10/100 ... MIPS st,Loongson1B Okay. +- reg: Address and length of the register set for the device +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupts: Should contain the STMMAC interrupts +- interrupt-names: Should contain the interrupt names macirq + eth_wake_irq if this interrupt is supported in the interrupts + property You should be able to tell this from the compatible string and number of interrupts. Yes. Currently the driver uses platform_get_irq_byname() to register the irq's. That's why I added these properties. Is there something wrong with using it this way? +- phy-mode: String, operation mode of the PHY interface. + Supported values are: mii, rmii, gmii, rgmii. +- phy-addr: MDIO address of the PHY This is normally probed or the mdio bus is a sub-node of the MAC node. See arch/powerpc/boot/dts/mpc8377_mds.dts for an example. Okay, I'll rework this. + +Optional properties: +- stm,prog-burst-len: Specify the burst length +- stm,has-gmac: Indicates that the controller supports 1000Mbps +- stm,has-pmt: Indicates that the controller supports power management I think these should all be encoded by the compatible string. and should we have all the other flags e.g. tx_coe etc? (see stmmac.txt) As Rob suggested, some of these flags/parameters are implicitly defined by the compatible string. If this is not the case, then sure, those flags/parameters need to be provided via the device-tree as well. I just don't need tx_coe etc. for my platform (SPEAr600) as far as I know. I suggest to add support for them once they are really needed/used by other platforms. Ok, but on SPEAr indeed some of these are not used at all. If you agree, we can go head with these and then we will add new ones next time. In the meantime, I will try to be more familiar with devicetree and provide further patches peppe Thanks, Stefan -- To unsubscribe from this list: send the line unsubscribe netdev 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 v1 1/5] ARM: imx28: add basic dt support
On 03/13/2012 09:35 AM, Rob Herring wrote:
+ ahb@8008 {
+ fec@800f {
Use generic names: ethernet@800f
Generic is good, but consistency is better, IMHO. grepping existing dts
files in 3.2.9 finds 6 instances of fec@ and 0 instances of ethernet@
+ uart1: uart@80074000 {
Use generic names: uart1: serial@...
Same comment here, but unfortunately there is already inconsistency in
existing files... 25 instances of serial@ and 35 instances of uart@
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[patch] max17042_battery: fix a couple buffer overflows
There are a couple issues here caused by confusion between sizeof()
and ARRAY_SIZE(). table_size should be the number of elements, but we
should allocate it with kcalloc() so that we allocate the correct number
of bytes.
In max17042_init_model() we don't allocate enough space so we go past
the end of the array in max17042_read_model_data() and
max17042_model_data_compare().
In max17042_verify_model_lock() we allocate the right amount of space
but we call max17042_read_model_data() with the wrong number of elements
and also in the for loop we go past the end of the array.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
---
I don't have this hardware. The original code is clearly buggy, but I
can't test that my fix is correct. Please review carefully.
diff --git a/drivers/power/max17042_battery.c b/drivers/power/max17042_battery.c
index e36763a..f8cd48c 100644
--- a/drivers/power/max17042_battery.c
+++ b/drivers/power/max17042_battery.c
@@ -328,11 +328,10 @@ static inline int max17042_model_data_compare(struct
max17042_chip *chip,
static int max17042_init_model(struct max17042_chip *chip)
{
int ret;
- int table_size =
- sizeof(chip-pdata-config_data-cell_char_tbl)/sizeof(u16);
+ int table_size = ARRAY_SIZE(chip-pdata-config_data-cell_char_tbl);
u16 *temp_data;
- temp_data = kzalloc(table_size, GFP_KERNEL);
+ temp_data = kcalloc(table_size, sizeof(*temp_data), GFP_KERNEL);
if (!temp_data)
return -ENOMEM;
@@ -357,12 +356,11 @@ static int max17042_init_model(struct max17042_chip *chip)
static int max17042_verify_model_lock(struct max17042_chip *chip)
{
int i;
- int table_size =
- sizeof(chip-pdata-config_data-cell_char_tbl);
+ int table_size = ARRAY_SIZE(chip-pdata-config_data-cell_char_tbl);
u16 *temp_data;
int ret = 0;
- temp_data = kzalloc(table_size, GFP_KERNEL);
+ temp_data = kcalloc(table_size, sizeof(*temp_data), GFP_KERNEL);
if (!temp_data)
return -ENOMEM;
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] Device Tree Bindings for Freescale TDM controller
From: Poonam Aggrwal poonam.aggr...@freescale.com
This TDM controller is available in various Freescale SOCs like MPC8315, P1020,
P1022, P1010.
Signed-off-by: Sandeep Singh sand...@freescale.com
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
Documentation/devicetree/bindings/tdm/fsl-tdm.txt | 71 +
1 files changed, 71 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/tdm/fsl-tdm.txt
diff --git a/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
new file mode 100644
index 000..61431e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/tdm/fsl-tdm.txt
@@ -0,0 +1,71 @@
+=
+TDM Device Tree Binding
+Copyright (C) 2012 Freescale Semiconductor Inc.
+
+NOTE: The bindings described in this document are preliminary
+and subject to change.
+
+=
+TDM (Time Division Multiplexing)
+
+DESCRIPTION
+
+The TDM is full duplex serial port designed to allow various devices including
+digital signal processors (DSPs) to communicate with a variety of serial
devices
+including industry standard framers, codecs, other DSPs and microprocessors.
+
+The below properties describe the device tree bindings for Freescale TDM
+controller.
+This TDM controller is available on various Freescale Processors like
+MPC8313, P1020, P1022 and P1010.
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type: string
+ Definition: Should contain fsl,mpc8315-tdm.
+ So mpc8313 will have compatible = fsl,mpc8315-tdm;
+ p1010 will have compatible fsl,p1010-tdm, fsl,mpc8315-tdm;
+
+ - reg
+ Usage: required
+ Value type: tdm-reg-offset tdm-reg-size dmac-reg-offset dmac-reg-size
+ Definition: A standard property. Specifies the physical address
+ offset and length of the TDM registers and TDM DMAC registers for
+ the device.
+
+ - clock-frequency
+ Usage: optional
+ Value type: u32
+ Definition: The frequency at which the TDM block is operating.
+
+ - interrupts
+ Usage: required
+ Value type: tdm-err-intr tdm-err-intr-type dmac-intr dmac-intr-type
+ Definition: This field defines two interrupt specifiers namely interrupt
+ number and interrupt type for TDM error and TDM DMAC.
+
+ - phy-handle
+ Usage: optional
+ Value type: phandle
+ Definition: Phandle of the line controller node or framer node eg. SLIC,
+ E1\T1 etc.
+
+ - fsl-max-time-slots
+ Usage: required
+ Value type: u32
+ Definition: Maximum number of 8-bit time slots in one TDM frame.
+ This is the maximum number which TDM hardware supports.
+
+EXAMPLE
+
+ tdm@16000 {
+ device_type = tdm;
+ compatible = fsl,p1010-tdm, fsl,mpc8315-tdm;
+ reg = 0x16000 0x200 0x2c000 0x2000;
+ clock-frequency = 0;
+ interrupts = 16 8 62 8;
+ phy-handle = zarlink1
+ fsl-max-time-slots = 128
+ };
--
1.5.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: EHCI_MV confusion was: Re: kirkwood devicetree respin
-Original Message- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: 2012年3月22日 0:28 To: Nicolas Pitre Cc: Neil Zhang; Jason Cooper; Arnd Bergmann; Andrew Lunn; Jamie Lentin; USB list; mich...@walle.cc; devicetree-discuss@lists.ozlabs.org Subject: Re: EHCI_MV confusion was: Re: kirkwood devicetree respin On Wed, 21 Mar 2012, Nicolas Pitre wrote: On Wed, 21 Mar 2012, Alan Stern wrote: On Wed, 21 Mar 2012, Jason Cooper wrote: On Tue, Mar 20, 2012 at 11:54:53PM -0400, Nicolas Pitre wrote: On Tue, 20 Mar 2012, Arnd Bergmann wrote: ehci-orion only makes sense on PLAT_ORION, and they never have any other platform ehci driver. ehci-mv only makese sense on PLAT_PXA, and they also don't have any other platform ehci driver. BTW, as someone who once was the active maintainer for PXA, and later the active maintainer for Orion, I should say that ehci-mv is a terribly bad name (as demonstrated, not all Marvell SOCs use ehci-mv) and confusion would be much reduced if it was renamed to ehci-pxa. I think there is still value in the rename. mv is a really bad qualifier for an IP block from a company that has many of them for the same purpose. We have submitted a patch to remove ehci-pxa168.c. And we have plan to rename the driver name for ehci-mv.c. Thanks. Then you should discuss this with the driver's maintainer (CC'ed). Alan Stern Best Regards, Neil Zhang ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: uImage with integrated dtb file
On 26/03/12 17:06, Stephen Warren wrote: quiet_cmd_uimage = UIMAGE $@ - cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \ + cmd_uimage = cat $ arch/arm/boot/*.dtb $.tmp ; \ That won't work well when multiple .dtb files are built. That's completely correct! Therefore I called it hack (maybe forgetting to prefix it ugly), so please don't use it. ;-) Roland ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/3] i2c-s3c2410: Add HDMIPHY quirk for S3C2440
Hi Karol,
Please refer to comments below,
Regards,
Tomasz Stanislawski
On 03/13/2012 05:54 PM, Karol Lewandowski wrote:
This patch adds support for s3c2440 I2C bus controller dedicated HDMIPHY
device on
Exynos4 platform. Some quirks are introduced due to differences between
HDMIPHY
and other I2C controllers on Exynos4. These differences are:
- no GPIOs, HDMIPHY is inside the SoC and the controller is connected
internally
- due to unknown reason (probably HW bug in HDMIPHY and/or the controller) a
transfer fails to finish. The controller hangs after sending the last byte,
the workaround for this bug is resetting the controller after each transfer
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Karol Lewandowski k.lewando...@samsung.com
Tested-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/i2c/samsung-i2c.txt| 10 -
drivers/i2c/busses/i2c-s3c2410.c | 36
2 files changed, 44 insertions(+), 2 deletions(-)
[snip]
@@ -871,6 +896,14 @@ s3c24xx_i2c_parse_dt(struct device_node *np, struct
s3c24xx_i2c *i2c)
return;
pdata-bus_num = -1; /* i2c bus number is dynamically assigned */
+
+ if (s3c24xx_i2c_is_type(i2c, TYPE_S3C2440)
I think that type checking should be removed because hdmiphy quirk is something
orthogonal to the controller type.
+ of_get_property(np, samsung,i2c-quirk-hdmiphy, NULL))
+ i2c-type |= FLAG_HDMIPHY;
+
+ if (of_get_property(np, samsung,i2c-no-gpio, NULL))
+ i2c-type |= FLAG_NO_GPIO;
+
of_property_read_u32(np, samsung,i2c-sda-delay, pdata-sda_delay);
of_property_read_u32(np, samsung,i2c-slave-addr, pdata-slave_addr);
of_property_read_u32(np, samsung,i2c-max-bus-freq,
@@ -1128,6 +1161,9 @@ static struct platform_device_id s3c24xx_driver_ids[] =
{
}, {
.name = s3c2440-i2c,
.driver_data= TYPE_S3C2440,
+ }, {
+ .name = s3c2440-hdmiphy-i2c,
+ .driver_data= TYPE_S3C2440 | FLAG_HDMIPHY | FLAG_NO_GPIO,
}, { },
};
MODULE_DEVICE_TABLE(platform, s3c24xx_driver_ids);
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 4/5] dma: mxs-dma: add dt probe support
Hi Aisheng:
From: Dong Aishengdong.aish...@linaro.org
Signed-off-by: Dong Aishengdong.aish...@linaro.org
---
.../devicetree/bindings/dma/fsl-mxs-dma.txt| 17
drivers/dma/mxs-dma.c | 44 +--
2 files changed, 47 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
new file mode 100644
index 000..cfa1730
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
@@ -0,0 +1,17 @@
+* Freescale MXS DMA
+
+Required properties:
+- compatible : Should be fsl,mxs-dma-apbh or fsl,mxs-dma-apbx
+- reg : Should contain registers location and length
+
+Examples:
+
+dma-apbh@80004000 {
+ compatible = fsl,mxs-dma-apbh;
+ reg =0x80004000 2000;
+};
+
+dma-apbx@80024000 {
+ compatible = fsl,mxs-dma-apbx;
+ reg =0x80024000 2000;
+};
diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c
index b06cd4c..45e8d46 100644
--- a/drivers/dma/mxs-dma.c
+++ b/drivers/dma/mxs-dma.c
@@ -22,6 +22,9 @@
#includelinux/platform_device.h
#includelinux/dmaengine.h
#includelinux/delay.h
+#includelinux/module.h
+#includelinux/of.h
+#includelinux/of_device.h
#includeasm/irq.h
#includemach/mxs.h
@@ -130,6 +133,25 @@ struct mxs_dma_engine {
struct mxs_dma_chan mxs_chans[MXS_DMA_CHANNELS];
};
+static struct platform_device_id mxs_dma_type[] = {
+ {
+ .name = mxs-dma-apbh,
+ .driver_data = MXS_DMA_APBH,
+ }, {
+ .name = mxs-dma-apbx,
+ .driver_data = MXS_DMA_APBX,
+ }, {
+ /* end of list */
+ }
+};
+
I think you should use the platform_device_id to distinguish different
archs.
In the mx6q, you will meet some compiler error for the macro cpu_is_mx23().
BR
Huang Shijie
+static const struct of_device_id mxs_dma_dt_ids[] = {
+ { .compatible = fsl,mxs-dma-apbh, .data =mxs_dma_type[0], },
+ { .compatible = fsl,mxs-dma-apbx, .data =mxs_dma_type[1], },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mxs_dma_dt_ids);
+
static void mxs_dma_reset_chan(struct mxs_dma_chan *mxs_chan)
{
struct mxs_dma_engine *mxs_dma = mxs_chan-mxs_dma;
@@ -587,8 +609,8 @@ err_out:
static int __init mxs_dma_probe(struct platform_device *pdev)
{
- const struct platform_device_id *id_entry =
- platform_get_device_id(pdev);
+ const struct platform_device_id *id_entry;
+ const struct of_device_id *of_id;
struct mxs_dma_engine *mxs_dma;
struct resource *iores;
int ret, i;
@@ -597,6 +619,11 @@ static int __init mxs_dma_probe(struct platform_device
*pdev)
if (!mxs_dma)
return -ENOMEM;
+ of_id = of_match_device(mxs_dma_dt_ids,pdev-dev);
+ if (of_id)
+ id_entry = of_id-data;
+ else
+ id_entry = platform_get_device_id(pdev);
mxs_dma-dev_id = id_entry-driver_data;
iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -679,21 +706,10 @@ err_request_region:
return ret;
}
-static struct platform_device_id mxs_dma_type[] = {
- {
- .name = mxs-dma-apbh,
- .driver_data = MXS_DMA_APBH,
- }, {
- .name = mxs-dma-apbx,
- .driver_data = MXS_DMA_APBX,
- }, {
- /* end of list */
- }
-};
-
static struct platform_driver mxs_dma_driver = {
.driver = {
.name = mxs-dma,
+ .of_match_table = mxs_dma_dt_ids,
},
.id_table = mxs_dma_type,
};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 5/5] ARM: mxs: add mxs dma dt support
Hi,
+ dma-apbh@80004000 {
+ compatible = fsl,mxs-dma-apbh;
+ reg =0x80004000 2000;
+ };
+
Why you do not add the `interrupt` for the it?
the gpmi-nand needs to parse the interrupt out.
BR
Huang Shijie
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 5/5] ARM: mxs: add mxs dma dt support
Hi Aisheng: The non-dt way also does not have interrupt resource for dma device. It seems the channel interrupt resource is handled in each client device. I'm not familiar with gpmi-nand, but I guess you may need to handle it in gpmi driver, just like mxs-mmc driver. ok, got it. thanks Huang Shijie ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] stmmac: Add device-tree support
On 3/12/2012 3:38 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 15:05 Mon 12 Mar , Stefan Roese wrote:
This patch adds support to configure the STMMAC ethernet driver via
device-tree instead of platform_data.
Currently, only the properties needed on SPEAr600 are provided. All
other properties should be added once needed on other platforms.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Giuseppe Cavallaro peppe.cavall...@st.com
Cc: Viresh Kumar viresh.ku...@st.com
---
Documentation/devicetree/bindings/net/stmmac.txt | 38 +++
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 66
+++-
2 files changed, 103 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/net/stmmac.txt
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
new file mode 100644
index 000..386a47f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -0,0 +1,38 @@
+* STMicroelectronics 10/100/1000 Ethernet driver (GMAC)
+
+Required properties:
+- compatible: Should be stm,gmac
this IP have 2 version at least the GMAC for the second generation and mac for
the first generation
yes you are right. STMMAC supports two device generations I named:
dwma10/100 and dwmac1000 (gmac).
Concerning the latter, we support several different versions of the
synopsys GMAC cores ... from 3.30 to 3.61a.
For example, stx7108 and Stx7109 have the same GMAC core (also SPEAr600
IIRC).
SPEAr13xx has 3.50a
New ST SoC Stxh415 has the 3.60a. etc.
+- reg: Address and length of the register set for the device
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- interrupts: Should contain the STMMAC interrupts
+- interrupt-names: Should contain the interrupt names macirq
+ eth_wake_irq if this interrupt is supported in the interrupts
+ property
optionnal
yes
note that there will be a new field for lpi IRQ as well
+- phy-mode: String, operation mode of the PHY interface.
+ Supported values are: mii, rmii, gmii, rgmii.
+- phy-addr: MDIO address of the PHY
+
+Optional properties:
+- stm,prog-burst-len: Specify the burst length
+- stm,has-gmac: Indicates that the controller supports 1000Mbps
this IP support more mode 10/100/300/1000
has_gmac was used to understand on devices w/o the HW cap registers if
the core is a gmac... another useful parameter could be : enh_desc
In fact, there are several possible HW configurations:
gmac core + enh desc
gmac core + norm_desc
mac core + norm_des
...
W/o cap register (present in new cores newer than 3.50) we need to pass
this info from the plt.
+- stm,has-pmt: Indicates that the controller supports power management
+- mac-address: 6 bytes, mac address
+
+Examples:
+
+gmac0: stmmac@e080 {
+compatible = stm,gmac;
+reg = 0xe080 0x8000;
+interrupt-parent = vic1;
+interrupts = 24 23;
+interrupt-names = macirq, eth_wake_irq;
+mac-address = []; /* Filled in by U-Boot */
+
+stm,prog-burst-len = 8;
+stm,has-gmac;
+stm,has-pmt;
+
+phy-mode = gmii;
+phy-addr = 0;
+};
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 3aad981..fcf46c7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -24,8 +24,43 @@
#include linux/platform_device.h
#include linux/io.h
+#include linux/of.h
+#include linux/of_net.h
#include stmmac.h
+#ifdef CONFIG_OF
+static int __devinit stmmac_probe_config_dt(struct platform_device *pdev,
+struct plat_stmmacenet_data *plat,
+const char **mac)
+{
+struct device_node *np = pdev-dev.of_node;
+
+if (!np)
+return -ENODEV;
+
+*mac = of_get_mac_address(np);
+
+plat-interface = of_get_phy_mode(np);
+of_property_read_u32(np, phy-addr, plat-phy_addr);
+plat-mdio_bus_data = devm_kzalloc(pdev-dev,
+ sizeof(struct stmmac_mdio_bus_data),
+ GFP_KERNEL);
+
+/*
+ * Currently only the properties needed on SPEAr600
+ * are provided. All other properties should be added
+ * once needed on other platforms.
+ */
+of_property_read_u32(np, stm,prog-burst-len, plat-pbl);
+if (of_get_property(np, stm,has-gmac, NULL))
+plat-has_gmac = 1;
+if (of_get_property(np, stm,has-pmt, NULL))
+plat-pmt = 1;
+
+return 0;
+}
+#endif /* CONFIG_OF */
+
/**
* stmmac_pltfr_probe
* @pdev: platform device pointer
@@ -39,7 +74,8 @@ static int
Re: [PATCH] stmmac: Add device-tree support
On 3/14/2012 2:07 PM, Arnd Bergmann wrote: On Wednesday 14 March 2012, Giuseppe CAVALLARO wrote: On 3/12/2012 3:38 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: On 15:05 Mon 12 Mar , Stefan Roese wrote: This patch adds support to configure the STMMAC ethernet driver via device-tree instead of platform_data. Currently, only the properties needed on SPEAr600 are provided. All other properties should be added once needed on other platforms. Signed-off-by: Stefan Roese s...@denx.de Cc: Giuseppe Cavallaro peppe.cavall...@st.com Cc: Viresh Kumar viresh.ku...@st.com --- Documentation/devicetree/bindings/net/stmmac.txt | 38 +++ .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 66 +++- 2 files changed, 103 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/net/stmmac.txt diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt new file mode 100644 index 000..386a47f --- /dev/null +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -0,0 +1,38 @@ +* STMicroelectronics 10/100/1000 Ethernet driver (GMAC) + +Required properties: +- compatible: Should be stm,gmac this IP have 2 version at least the GMAC for the second generation and mac for the first generation yes you are right. STMMAC supports two device generations I named: dwma10/100 and dwmac1000 (gmac). Concerning the latter, we support several different versions of the synopsys GMAC cores ... from 3.30 to 3.61a. For example, stx7108 and Stx7109 have the same GMAC core (also SPEAr600 IIRC). SPEAr13xx has 3.50a New ST SoC Stxh415 has the 3.60a. etc. In that case, you should definitely list the exact device versions in the compatible string, like: compatible = stm,spear600-gmac, snps,dw-gmac-3.50a, snps,dw-gmac; looks good to me When we have other socs with the same version, that lets us add quirks for the specific version by checking the compatible property once in the driver. It also sounds to me that the entire stmmac driver should live in the drivers/net/ethernet/synopsys directory, not stmicro, but that is a different issue. I had also proposed to rename it from stmmac to synmac. peppe Arnd -- To unsubscribe from this list: send the line unsubscribe netdev 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] stmmac: Add device-tree support
On 3/14/2012 5:26 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: On 12:38 Wed 14 Mar , Giuseppe CAVALLARO wrote: On 3/12/2012 3:38 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: On 15:05 Mon 12 Mar , Stefan Roese wrote: This patch adds support to configure the STMMAC ethernet driver via device-tree instead of platform_data. Currently, only the properties needed on SPEAr600 are provided. All other properties should be added once needed on other platforms. Signed-off-by: Stefan Roese s...@denx.de Cc: Giuseppe Cavallaro peppe.cavall...@st.com Cc: Viresh Kumar viresh.ku...@st.com --- Documentation/devicetree/bindings/net/stmmac.txt | 38 +++ .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 66 +++- 2 files changed, 103 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/net/stmmac.txt diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt new file mode 100644 index 000..386a47f --- /dev/null +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -0,0 +1,38 @@ +* STMicroelectronics 10/100/1000 Ethernet driver (GMAC) + +Required properties: +- compatible: Should be stm,gmac this IP have 2 version at least the GMAC for the second generation and mac for the first generation yes you are right. STMMAC supports two device generations I named: dwma10/100 and dwmac1000 (gmac). Concerning the latter, we support several different versions of the synopsys GMAC cores ... from 3.30 to 3.61a. For example, stx7108 and Stx7109 have the same GMAC core (also SPEAr600 IIRC). no PM the PM was only since 7108 IIRC Sorry! you are right :-) 7109 has the mac10/100 (databook 1.91) and 7105/8 have the gmac databook 3.30. peppe 7109 use mac not gmac IIRC it's 7105 that start to use the GMAC with 300Mbps max SPEAr13xx has 3.50a New ST SoC Stxh415 has the 3.60a. etc. +- reg: Address and length of the register set for the device +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupts: Should contain the STMMAC interrupts +- interrupt-names: Should contain the interrupt names macirq + eth_wake_irq if this interrupt is supported in the interrupts + property optionnal yes note that there will be a new field for lpi IRQ as well +- phy-mode: String, operation mode of the PHY interface. + Supported values are: mii, rmii, gmii, rgmii. +- phy-addr: MDIO address of the PHY + +Optional properties: +- stm,prog-burst-len: Specify the burst length +- stm,has-gmac: Indicates that the controller supports 1000Mbps this IP support more mode 10/100/300/1000 has_gmac was used to understand on devices w/o the HW cap registers if the core is a gmac... another useful parameter could be : enh_desc this need to manage via compatible Best Regards, J. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: SPEAr600: Add device-tree support to SPEAr600 boards
On Wed, Mar 21, 2012 at 6:06 PM, Arnd Bergmann a...@arndb.de wrote: Let's make sure we're on the same page with the process though. I hope you're aware that I took Stefan's spear6xx v5 patch. Ya. I already know that. :) Just let me know how you want to handle these things in the future -- the normal way would be to always let you forward the patches to me, rather than having them applied to arm-soc directly. Hmmm. I don't know how exactly it works, but maybe you can add me as an custodian for SPEAr, with a git repo somewhere in kernel.org (?). So that i can apply patches directly to my branch, you pull it. What do you say? I think spear is simple and clean enough that it can serve as an example for others doing DT conversion. Do you also plan to unify 3xx and 6xx? I think there is hardly anything left in mach-spear6xx that justifies having a separate platform, especially since with the DT conversion done, we can actually remove most of the header file contents as well. I issue with us was that we were not able to push stuff mainline in time and were too busy supporting customers. We have lot of patches locally, that we would like to upstream. But it can't happen without updating it with new expectations of list. I actually wanted to ask you few things: - DT: Obviously we would have this in our patches - Pinmux: I would remove our padmux and use pinmux, but what about its DT support. I know stephen had few patches for it, but don't know there progress. I don't want to do stuff twice. First add support for it in board and the *.dts files. - Clock Framework: Is common clock framework ready for use or can we update our local clock framework? I will see if merging 3xx 6xx is feasible. If yes, then i will surely move in that direction. I always like cleaning stuff. :) I would be adding 13xx (cortex-A9) patches again later, once done with 3xx. -- viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: SPEAr600: Add device-tree support to SPEAr600 boards
On Wed, Mar 21, 2012 at 7:34 PM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 21 March 2012, viresh kumar wrote: - Pinmux: I would remove our padmux and use pinmux, but what about its DT support. I know stephen had few patches for it, but don't know there progress. I don't want to do stuff twice. First add support for it in board and the *.dts files. AFAICT, the pinmux DT binding should be ready for v3.5, I don't think it made it into v3.4. So, i can add stuff in board file for pinmux for now? I've looked at this earlier today out of curiosity and found: clock.c: almost identical, can be easily merged, or both copies kept around during transition. Would make it very confusing if we merge these two. Some clock structures are same, but others are not. Mostly differences are in the macros (or bit positions in registers), rather than hierarchy. So, i would like to keep them separate. But still have a look again to see if they can really be merged. misc_regs.h: can be merged into clock.c it has more than clock stuff. it is used in pinmux and some other places too, that may not be in mainline for now. Once you have taken care of these, files, you can enable building 3xx and 6xx together, and move the contents of mach-spear3xx, mach-spear6xx and plat-spear into one directory. plat-spear would be required for 13xx too. So, merging 3xx and 6xx only would be possible. Ok, excellent. Note that there is no requirement to do it all in the order you line out above. You can always get support for new stuff into the existing platform without cleaning up all of it right away, as long as you have a good balance between cleanups and new functionality. Ya. I just wanted to get some hands on experience with this new stuff, before touching 13xx. In particular, you don't have to start using pinctrl and the common clk immediately for spear3xx, although you might find that it helps you. But, can i update padmux and clock framework of SPEAr platform? Because without the latest code for both padmux and clock, other code for SPEAr might not be that effective or usable. For spear13xx, the platform being completely new, I would however ask you to use those from the start. Sure. -- viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: kirkwood devicetree respin
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Felipe Balbi
Sent: Wednesday, March 21, 2012 6:23 AM
On Wed, Mar 21, 2012 at 01:17:38PM +, Arnd Bergmann wrote:
On Wednesday 21 March 2012, Felipe Balbi wrote:
I have explained an easy way to achieve that to Alan Stern, but he did
not like it. Basically, we should add a platform_device to ehci-hcd.ko
and make ehci-{omap,mv,fsl,atmel,etc} a parent device/driver which
basically passes the correct resources and handle platform-specific
details.
That way, we could build everything together and udev would load the
correct modules for us.
For an example of what I mean, see drivers/usb/dwc3/core.c,
drivers/usb/dwc3/dwc3-omap.c, and drivers/usb/dwc3/dwc3-pci.c
While that way clearly works and can solve the problem we have
with ehci today, I think it's easier and more consistent with
other drivers to do it the opposite way, as we have recently
discussed in the context of ohci:
Make the base driver a loadable module that does not register
any struct device_driver at all, but just exports functions to
other module. The hardware specific drivers then each register
to their own bus and use the functions exported by the
main driver, with a way to override them with their own versions.
Alan suggested a variation of that where we actually export
a default struct hc_driver instead of the individual functions,
which has the advantage of having to export fewer symbols, but
otherwise is similar to what we do elsewhere.
See libata, sdhci, serial-8250 or xhci for examples of this way.
that is likely to work, indeed. My suggestion would make PM simpler
though and avoid some code duplication in the long run, meaning that
ehci-hcd.ko could have its own dev_pm_ops which e.g. knows how to save
EHCI's context while ehci-omap.c knows how to save OMAP-specific
context, toggle clocks, set pads in safe mode (when needed) and so on.
But fair enough, both ways would work fine.
I would also recommend your/Alan's approach to this over Felipe's way.
We have a DWC3 platform with an (admittedly oddball) PM implementation
that requires the bus driver to have some knowledge of the base driver's
internal state, and needs the two drivers to be able to communicate with
each other. With the base driver being a separate platform device, this
is nearly impossible to achieve in a clean way. If the DWC3 driver was
designed the way you and Alan are recommending, it would be easy.
I'm trying to convince Felipe to change the DWC3 driver design to
accommodate this, but I hold out little hope for that :)
--
Paul
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: SPEAr600: Add device-tree support to SPEAr600 boards
On Wed, Mar 21, 2012 at 11:56 PM, Arnd Bergmann a...@arndb.de wrote: I just noticed that you have git trees on http://git.stlinux.com/, which I would personally prefer you to use actually. git.kernel.org is most useful for people that don't have their own git servers. Ah, that's even better for me too. I don't really have to manage two trees. Just to understand the flow, how does this work now? There can be two sources of patches: - From ST internal developers - From external developers Should i apply them all to my tree and then send you a pull request? Or you automatically pull everyday from some specific branch? Sorry i am new to this. :( -- viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: SPEAr600: Add device-tree support to SPEAr600 boards
On Mar 22, 2012 1:40 PM, Arnd Bergmann a...@arndb.de wrote: Don't hesitate to ask if you have further process questions, I know this can be confusing and we're doing things much stricter than other maintainters in order to keep up with ~600 patches per merge window. Everything is clear. Thanks. -- Viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: SPEAr600: Add device-tree support to SPEAr600 boards
On Mar 21, 2012 6:09 PM, Arnd Bergmann a...@arndb.de wrote: Regarding the spear3xx patches, I'm looking forward to your patches. I think spear is simple and clean enough that it can serve as an example for others doing DT conversion. Hi Arnd, I was doing DT stuff for 3xx and have a doubt regarding DT. How are boards identified at runtime now? Earlier we had machine_is_*() to do that. Also why are both DT_MACHINE_START and MACHINE_START present on some SoC's? -- Viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: SPEAr600: Add device-tree support to SPEAr600 boards
On Mar 22, 2012 7:50 PM, Arnd Bergmann a...@arndb.de wrote: The direct replacement is of_machine_is_compatible(), but there are a lot of cases where it's better to have a local property in the device node that a driver is using. Thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: kirkwood devicetree respin
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Thursday, March 22, 2012 1:13 AM
On Wed, Mar 21, 2012 at 08:06:12PM +, Paul Zimmerman wrote:
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Felipe
Balbi
Sent: Wednesday, March 21, 2012 6:23 AM
On Wed, Mar 21, 2012 at 01:17:38PM +, Arnd Bergmann wrote:
On Wednesday 21 March 2012, Felipe Balbi wrote:
I have explained an easy way to achieve that to Alan Stern, but he did
not like it. Basically, we should add a platform_device to ehci-hcd.ko
and make ehci-{omap,mv,fsl,atmel,etc} a parent device/driver which
basically passes the correct resources and handle platform-specific
details.
That way, we could build everything together and udev would load the
correct modules for us.
For an example of what I mean, see drivers/usb/dwc3/core.c,
drivers/usb/dwc3/dwc3-omap.c, and drivers/usb/dwc3/dwc3-pci.c
While that way clearly works and can solve the problem we have
with ehci today, I think it's easier and more consistent with
other drivers to do it the opposite way, as we have recently
discussed in the context of ohci:
Make the base driver a loadable module that does not register
any struct device_driver at all, but just exports functions to
other module. The hardware specific drivers then each register
to their own bus and use the functions exported by the
main driver, with a way to override them with their own versions.
Alan suggested a variation of that where we actually export
a default struct hc_driver instead of the individual functions,
which has the advantage of having to export fewer symbols, but
otherwise is similar to what we do elsewhere.
See libata, sdhci, serial-8250 or xhci for examples of this way.
that is likely to work, indeed. My suggestion would make PM simpler
though and avoid some code duplication in the long run, meaning that
ehci-hcd.ko could have its own dev_pm_ops which e.g. knows how to save
EHCI's context while ehci-omap.c knows how to save OMAP-specific
context, toggle clocks, set pads in safe mode (when needed) and so on.
But fair enough, both ways would work fine.
I would also recommend your/Alan's approach to this over Felipe's way.
We have a DWC3 platform with an (admittedly oddball) PM implementation
that requires the bus driver to have some knowledge of the base driver's
internal state, and needs the two drivers to be able to communicate with
each other. With the base driver being a separate platform device, this
is nearly impossible to achieve in a clean way. If the DWC3 driver was
designed the way you and Alan are recommending, it would be easy.
I'm trying to convince Felipe to change the DWC3 driver design to
accommodate this, but I hold out little hope for that :)
yeah, I'm not thinking on taking that patch, sorry. Didn't you say SNPS
had agreed on rebuilding the FPGA system so that it's a more standard
PCIe implementation ?
I still owe you another possible implementation for the whole PM thing,
sorry about the delay.
Dropped the other folks from CC since they probably aren't interested.
The FPGA rework is very low priority, those guys have more important
stuff to work on at the moment. Plus management doesn't understand
why the current design won't work, since the Synopsys driver supports
it OK.
So I'm not sure when the FPGA rework will happen.
--
Paul
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/4] mmc: atmel-mci: add device tree support
On Thu, Mar 22, 2012 at 03:50:48PM +0100, Nicolas Ferre wrote:
On 03/21/2012 07:03 PM, ludovic.desroc...@atmel.com :
[...]
diff --git a/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
b/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
new file mode 100644
index 000..657f9de
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
@@ -0,0 +1,55 @@
+* Atmel High Speed MultiMedia Card Interface
+
+This controller on atmel products provides an interface for MMC, SD and
SDIO
+types of memory cards.
+
+1) MCI node
+
+Required properties:
+- compatible: no blank atmel,hsmci
+- reg: should contain HSMCI registers location and length
+- interrupts: should contain HSMCI interrupt number
+- at least one slot node
+
+The node contains child nodes for each slot that the platform uses
+
+Example MCI node:
+
+mmc0: mmc@f0008000 {
+ compatible = atmel,hsmci;
+ reg = 0xf0008000 0x600;
+ interrupts = 12 4;
+
+ [ child node definitions...]
+};
+
+2) slot nodes
+
+Optional properties:
+- bus-width: number of data lines connected to the controller
+- cd-gpios: specify GPIOs for card detection
+- cd-invert: invert the value of external card detect gpio line
+- wp-gpios: specify GPIOs for write protection
+
+Example slot node:
+
+slot@0 {
+ bus-width = 4;
+ cd-gpios = pioD 15 0
+ cd-invert;
+};
+
+Example full MCI node:
+mmc0: mmc@f0008000 {
+ compatible = atmel,hsmci;
+ reg = 0xf0008000 0x600;
+ interrupts = 12 4;
+ slot@0 {
+ bus-width = 4;
+ cd-gpios = pioD 15 0
+ cd-invert;
+ };
+ slot@1 {
+ bus-width = 4;
+ };
+};
[...]
+static void __init
+atmci_get_of_slots(struct device *dev, struct mci_platform_data *pdata)
+{
+ struct device_node *np = dev-of_node;
+ struct device_node *cnp;
+ unsigned int slot_nb = 0;
+
+ if (!np)
+ return;
+
+ for_each_child_of_node(np, cnp) {
+ if (slot_nb (ATMCI_MAX_NR_SLOTS-1)) {
+ dev_warn(dev, can't have more than %d slots\n,
+ATMCI_MAX_NR_SLOTS);
+ break;
+ }
+ if (of_property_read_u32(cnp, bus-width,
+pdata-slot[slot_nb].bus_width))
+ pdata-slot[slot_nb].bus_width = 1;
+
+ pdata-slot[slot_nb].detect_pin =
+ of_get_named_gpio(cnp, cd-gpios, 0);
+
+ if (of_find_property(cnp, cd-invert, NULL))
+ pdata-slot[slot_nb].detect_is_active_high = true;
+
+ pdata-slot[slot_nb].wp_pin =
+ of_get_named_gpio(cnp, wp-gpios, 0);
+
+ slot_nb++;
+ }
+}
In fact this part of code is not correct. Each mci can have two slots: slot0
and slot1. If someone wants to use only slot1, I will fill only pdata-slot[0]
that is incorrect because later in the driver there is:
if (pdata-slot[0].bus_width) {
ret = atmci_init_slot(host, pdata-slot[0],
0, ATMCI_SDCSEL_SLOT_A, ATMCI_SDIOIRQA);
if (!ret)
nr_slots++;
}
if (pdata-slot[1].bus_width) {
ret = atmci_init_slot(host, pdata-slot[1],
1, ATMCI_SDCSEL_SLOT_B, ATMCI_SDIOIRQB);
if (!ret)
nr_slots++;
}
So what is the best solution to solve this issue?
- Adding a property slot id? I would like to use only existing bindings hoping
we can have a generic binding for mmc.
- Using aliases?
aliases {
slot0 = mmc-slot0;
}
mmc0: mmc@f0008000 {
compatible = atmel,hsmci;
reg = 0xf0008000 0x600;
interrupts = 12 4;
mmc-slot0: slot@0 {
};
status = disabled;
};
- Using reg property as an index?
Thanks for your help.
Regards
Ludovic
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: GIC: Create common infrastructure for GIC DT bindings
On Fri, Mar 23, 2012 at 7:49 AM, Viresh Kumar viresh.ku...@st.com wrote:
Few platforms define there own struct of_device_id[] for GIC. They don't
do anything specific in init_irq() other than of_irq_init().
This patch creates this struct array in gic.c and make other platforms use
it.
Signed-off-by: Viresh Kumar viresh.ku...@st.com
---
arch/arm/common/gic.c | 10 ++
arch/arm/include/asm/hardware/gic.h |1 +
arch/arm/mach-exynos/common.c |9 +
arch/arm/mach-highbank/highbank.c |7 +--
arch/arm/mach-imx/mach-imx6q.c |2 +-
arch/arm/mach-tegra/common.c|7 +--
arch/arm/mach-ux500/cpu.c |7 +--
arch/arm/mach-vexpress/v2m.c| 12 +---
8 files changed, 17 insertions(+), 38 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index aa52699..77afdae 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -781,4 +781,14 @@ int __init gic_of_init(struct device_node *node,
struct device_node *parent)
gic_cnt++;
return 0;
}
+
+static const struct of_device_id gic_of_match[] __initconst = {
+ { .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
+ { /* Sentinel */ }
+};
+
+void __init gic_init_irq(void)
+{
+ of_irq_init(gic_of_match);
+}
#endif
diff --git a/arch/arm/include/asm/hardware/gic.h
b/arch/arm/include/asm/hardware/gic.h
index 4b1ce6c..7bce4bd 100644
--- a/arch/arm/include/asm/hardware/gic.h
+++ b/arch/arm/include/asm/hardware/gic.h
@@ -42,6 +42,7 @@ void gic_init_bases(unsigned int, int, void __iomem *,
void __iomem *,
u32 offset, struct device_node *);
int gic_of_init(struct device_node *node, struct device_node *parent);
void gic_secondary_init(unsigned int);
+void __init gic_init_irq(void);
void gic_handle_irq(struct pt_regs *regs);
void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
void gic_raise_softirq(const struct cpumask *mask, unsigned int irq);
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 85ed8b5..76f6079 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -502,13 +502,6 @@ static void __init combiner_init(unsigned int
combiner_nr, void __iomem *base,
}
}
-#ifdef CONFIG_OF
-static const struct of_device_id exynos4_dt_irq_match[] = {
- { .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
- {},
-};
-#endif
-
void __init exynos4_init_irq(void)
{
int irq;
@@ -520,7 +513,7 @@ void __init exynos4_init_irq(void)
gic_init_bases(0, IRQ_PPI(0), S5P_VA_GIC_DIST,
S5P_VA_GIC_CPU, gic_bank_offset, NULL);
#ifdef CONFIG_OF
else
- of_irq_init(exynos4_dt_irq_match);
+ gic_init_irq();
#endif
for (irq = 0; irq EXYNOS4_MAX_COMBINER_NR; irq++) {
diff --git a/arch/arm/mach-highbank/highbank.c
b/arch/arm/mach-highbank/highbank.c
index 410a112..42b30c6 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -80,14 +80,9 @@ void highbank_set_cpu_jump(int cpu, void *jump_addr)
HB_JUMP_TABLE_PHYS(cpu) + 15);
}
-const static struct of_device_id irq_match[] = {
- { .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
- {}
-};
-
static void __init highbank_init_irq(void)
{
- of_irq_init(irq_match);
+ gic_init_irq();
l2x0_of_init(0, ~0UL);
}
diff --git a/arch/arm/mach-imx/mach-imx6q.c
b/arch/arm/mach-imx/mach-imx6q.c
index 7696dfa..ebaf6c5 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -105,7 +105,6 @@ static int __init imx6q_gpio_add_irq_domain(struct
device_node *np,
}
static const struct of_device_id imx6q_irq_match[] __initconst = {
- { .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
{ .compatible = fsl,imx6q-gpio, .data =
imx6q_gpio_add_irq_domain, },
{ /* sentinel */ }
};
@@ -115,6 +114,7 @@ static void __init imx6q_init_irq(void)
l2x0_of_init(0, ~0UL);
imx_src_init();
imx_gpc_init();
+ gic_init_irq();
of_irq_init(imx6q_irq_match);
}
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index 22df10f..c8d6208 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -52,15 +52,10 @@ u32 tegra_uart_config[3] = {
};
#ifdef CONFIG_OF
-static const struct of_device_id tegra_dt_irq_match[] __initconst = {
- { .compatible = arm,cortex-a9-gic, .data = gic_of_init },
- { }
-};
-
void __init tegra_dt_init_irq(void)
{
tegra_init_irq();
- of_irq_init(tegra_dt_irq_match);
+ gic_init_irq();
}
#endif
diff --git a/arch/arm/mach-ux500/cpu.c b/arch/arm/mach-ux500/cpu.c
index d11f389..3bb6f13 100644
--- a/arch/arm/mach-ux500/cpu.c
+++
Re: [git pull] PCI changes (including maintainer change)
On Thu, Mar 22, 2012 at 2:48 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
The following changes since commit
4f262acfde22b63498b5e4f165e53d3bb4e96400:
Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm
(2012-03-07 08:33:03 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci linux-next
This pull has some good cleanups from Bjorn and Yinghai, as well as
some more code from Yinghai to better handle resource re-allocation
when enabled.
There's also a new initcall_debug feature from Arjan which will print
out quirk timing information to help identify slow quirks for fixing or
refinement (Yinghai sent in a few patches to do just that once the new
debug code landed).
Beyond that, I'm handing off PCI maintainership to Bjorn Helgaas. He's
been a core PCI and Linux contributor for some time now, and has kindly
volunteered to take over. I just don't feel I have the time for PCI
review and work that it deserves lately (I've taken on some other
projects), and haven't been as responsive lately as I'd like, so I
approached Bjorn asking if he'd like to manage things. He's going to
give it a try, and I'm confident he'll do at least as well as I have in
keeping the tree managed, patches flowing, and keeping things stable.
There are some merge conflicts. Hope attached patch could help Linus a
little bit.
Yinghai
---
arch/mips/pci/pci.c |6
arch/powerpc/include/asm/ppc-pci.h |3
arch/powerpc/platforms/iseries/pci.c | 919 ---
include/linux/pci.h |4
4 files changed, 932 deletions(-)
Index: linux-2.6/arch/mips/pci/pci.c
===
--- linux-2.6.orig/arch/mips/pci/pci.c
+++ linux-2.6/arch/mips/pci/pci.c
@@ -250,25 +250,19 @@ int pcibios_enable_device(struct pci_dev
void __devinit pcibios_fixup_bus(struct pci_bus *bus)
{
- HEAD
/* Propagate hose info into the subordinate devices. */
-===
- pci/linux-next
struct pci_dev *dev = bus-self;
if (pci_has_flag(PCI_PROBE_ONLY) dev
(dev-class 8) == PCI_CLASS_BRIDGE_PCI) {
pci_read_bridge_bases(bus);
- HEAD
pcibios_fixup_device_resources(dev, bus);
}
list_for_each_entry(dev, bus-devices, bus_list) {
if ((dev-class 8) != PCI_CLASS_BRIDGE_PCI)
pcibios_fixup_device_resources(dev, bus);
-===
- pci/linux-next
}
}
Index: linux-2.6/arch/powerpc/include/asm/ppc-pci.h
===
--- linux-2.6.orig/arch/powerpc/include/asm/ppc-pci.h
+++ linux-2.6/arch/powerpc/include/asm/ppc-pci.h
@@ -45,12 +45,9 @@ extern void init_pci_config_tokens (void
extern unsigned long get_phb_buid (struct device_node *);
extern int rtas_setup_phb(struct pci_controller *phb);
- HEAD
extern unsigned long pci_probe_only;
-===
/* EEH internal-use-only related routines */
- pci/linux-next
#ifdef CONFIG_EEH
void pci_addr_cache_build(void);
Index: linux-2.6/arch/powerpc/platforms/iseries/pci.c
===
--- linux-2.6.orig/arch/powerpc/platforms/iseries/pci.c
+++ /dev/null
@@ -1,919 +0,0 @@
-/*
- * Copyright (C) 2001 Allan Trautman, IBM Corporation
- * Copyright (C) 2005,2007 Stephen Rothwell, IBM Corp
- *
- * iSeries specific routines for PCI.
- *
- * Based on code from pci.c and iSeries_pci.c 32bit
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#undef DEBUG
-
-#include linux/jiffies.h
-#include linux/kernel.h
-#include linux/list.h
-#include linux/string.h
-#include linux/slab.h
-#include linux/init.h
-#include linux/pci.h
-#include linux/of.h
-#include linux/ratelimit.h
-
-#include asm/types.h
-#include asm/io.h
-#include asm/irq.h
-#include asm/prom.h
-#include asm/machdep.h
-#include asm/pci-bridge.h
-#include asm/iommu.h
-#include asm/abs_addr.h
-#include asm/firmware.h
-
-#include asm/iseries/hv_types.h
-#include asm/iseries/hv_call_xm.h
-#include asm/iseries/mf.h
-#include asm/iseries/iommu.h
-
-#include asm/ppc-pci.h
-
-#include irq.h
-#include pci.h
-#include call_pci.h
-
-#define PCI_RETRY_MAX 3
-static int limit_pci_retries = 1; /* Set Retry Error on. */
-
-/*
- * Table defines
- * Each Entry
Re: [git pull] PCI changes (including maintainer change)
On Fri, Mar 23, 2012 at 2:10 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Fri, Mar 23, 2012 at 12:58 PM, Yinghai Lu ying...@kernel.org wrote: There are some merge conflicts. Hope attached patch could help Linus a little bit. Hmm. My merge does not agree with yours at all in the MIPS pcibios_fixup_bus() area. Your patch re-introduces the device resource fixup that Bjorn removed, for example. I think my merge is correct, but hey, people should double-check. yes, you are right. Yinghai ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mtd: spear-smi: Update compatible property
On Fri, Mar 23, 2012 at 7:40 PM, Rob Herring robherri...@gmail.com wrote: On 03/23/2012 03:48 AM, Viresh Kumar wrote: SPEAr SMI controller version is same for all SPEAr machines. Thus we don't need per machine compatible property in driver. Until the next chip... Sorry couldn't get you point here. Thus this patch updates compatible entry to: st,spear-smi, so that it works for all SPEAr machines. There is no reason all machines can't use st,spear600-smi in their dts. It doesn't have to be a spear600, just compatible with it. Really you want the string to be the oldest SOC the block is in and then newer SOCs can claim compatibility with the old version. Got your point. But actually as we just had smi DT support patch recently, so we can name it better right now. In future, i agree with your point. This is also bad that you would break any existing dtb's out there. This is probably not a concern yet since it's all new and in transition, but down the road this is something that can't be done. Yes i agree. Actually i had patch for spear600-evb.dts ready with me, but just wanted to have inputs on this change before posting the complete patchset. Would post both patches again, with my 3xx DT support. -- viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: VIC: Create common infrastructure for vic DT bindings
On Fri, Mar 23, 2012 at 6:10 PM, Rob Herring robherri...@gmail.com wrote: NAK None of these platforms have gpio interrupts or any other board interrupt controllers which need to be initialized early? Atleast SPEAr600 have GPIO interrupts. I don't think DT conversions are complete enough to tell. Couldn't get your comment, sorry. We could do something like this, but there only needs to be a single match list of all controllers and function. We should consolidate the irqchips to drivers/irqchip first though. I have that action from Connect... That would be good. I am updating DT support for SPEAr3xx, where i need to use VIC OF support. So i would still like to get this patch going and you can consilidate code at irqchips level later. What do you say? -- viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 1/2] mfd: add irq domain support for max8997 interrupts
On Sat, Mar 24, 2012 at 6:49 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
Add irq domain support for max8997 interrupts. The reverse mapping method
used is linear mapping since the sub-drivers of max8997 such as regulator
and charger drivers can use the max8997 irq_domain to get the linux irq
number for max8997 interrupts. All uses of irq_base in platform data and
max8997 driver private data are removed.
Cc: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Acked-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: MyungJoo Ham myungjoo@samsung.com
---
arch/arm/mach-exynos/mach-nuri.c | 4 --
arch/arm/mach-exynos/mach-origen.c | 1 -
drivers/mfd/max8997-irq.c | 61 --
drivers/mfd/max8997.c | 1 -
include/linux/mfd/max8997-private.h | 4 ++-
include/linux/mfd/max8997.h | 1 -
6 files changed, 39 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index 7ac81ce..b21d85d 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -1077,12 +1077,8 @@ static struct platform_device nuri_max8903_device = {
static void __init nuri_power_init(void)
{
int gpio;
- int irq_base = IRQ_GPIO_END + 1;
int ta_en = 0;
- nuri_max8997_pdata.irq_base = irq_base;
- irq_base += MAX8997_IRQ_NR;
-
gpio = EXYNOS4_GPX0(7);
gpio_request(gpio, AP_PMIC_IRQ);
s3c_gpio_cfgpin(gpio, S3C_GPIO_SFN(0xf));
diff --git a/arch/arm/mach-exynos/mach-origen.c
b/arch/arm/mach-exynos/mach-origen.c
index 827cb99..d3b2e9d 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -424,7 +424,6 @@ static struct max8997_platform_data __initdata
origen_max8997_pdata = {
.buck1_gpiodvs = false,
.buck2_gpiodvs = false,
.buck5_gpiodvs = false,
- .irq_base = IRQ_GPIO_END + 1,
.ignore_gpiodvs_side_effect = true,
.buck125_default_idx = 0x0,
diff --git a/drivers/mfd/max8997-irq.c b/drivers/mfd/max8997-irq.c
index 09274cf..00390a1 100644
--- a/drivers/mfd/max8997-irq.c
+++ b/drivers/mfd/max8997-irq.c
@@ -142,7 +142,8 @@ static void max8997_irq_sync_unlock(struct irq_data *data)
static const inline struct max8997_irq_data *
irq_to_max8997_irq(struct max8997_dev *max8997, int irq)
{
- return max8997_irqs[irq - max8997-irq_base];
+ struct irq_data *data = irq_get_irq_data(irq);
+ return max8997_irqs[data-hwirq];
}
static void max8997_irq_mask(struct irq_data *data)
@@ -182,7 +183,7 @@ static irqreturn_t max8997_irq_thread(int irq, void *data)
u8 irq_reg[MAX8997_IRQ_GROUP_NR] = {};
u8 irq_src;
int ret;
- int i;
+ int i, cur_irq;
ret = max8997_read_reg(max8997-i2c, MAX8997_REG_INTSRC, irq_src);
if (ret 0) {
@@ -269,8 +270,11 @@ static irqreturn_t max8997_irq_thread(int irq, void
*data)
/* Report */
for (i = 0; i MAX8997_IRQ_NR; i++) {
- if (irq_reg[max8997_irqs[i].group] max8997_irqs[i].mask)
- handle_nested_irq(max8997-irq_base + i);
+ if (irq_reg[max8997_irqs[i].group] max8997_irqs[i].mask) {
+ cur_irq = irq_find_mapping(max8997-irq_domain, i);
+ if (cur_irq)
+ handle_nested_irq(cur_irq);
+ }
}
return IRQ_HANDLED;
@@ -278,26 +282,40 @@ static irqreturn_t max8997_irq_thread(int irq, void
*data)
int max8997_irq_resume(struct max8997_dev *max8997)
{
- if (max8997-irq max8997-irq_base)
- max8997_irq_thread(max8997-irq_base, max8997);
+ if (max8997-irq max8997-irq_domain)
+ max8997_irq_thread(0, max8997);
+ return 0;
+}
+
+static int max8997_irq_domain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hw)
+{
+ struct max8997_dev *max8997 = d-host_data;
+
+ irq_set_chip_data(irq, max8997);
+ irq_set_chip_and_handler(irq, max8997_irq_chip, handle_edge_irq);
+ irq_set_nested_thread(irq, 1);
+#ifdef CONFIG_ARM
+ set_irq_flags(irq, IRQF_VALID);
+#else
+ irq_set_noprobe(irq);
+#endif
return 0;
}
+static struct irq_domain_ops max8997_irq_domain_ops = {
+ .map = max8997_irq_domain_map,
+};
+
int max8997_irq_init(struct max8997_dev *max8997)
{
+ struct irq_domain *domain;
int i;
- int cur_irq;
int ret;
u8 val;
if (!max8997-irq) {
dev_warn(max8997-dev, No interrupt specified.\n);
- max8997-irq_base = 0;
- return 0;
- }
-
- if (!max8997-irq_base) {
- dev_err(max8997-dev, No interrupt base
Re: [PATCH 2/2] Input: spear-keyboard: add device tree bindings
On Mar 26, 2012 9:00 PM, Stephen Warren swar...@wwwdotorg.org wrote: +- compatible: st,spear-kbd Should spear include some version number so that there's a clear path if/when future SoCs need a different binding? Ya. I will name it spear300-kbd. +- mode: keyboard mode: 0 - 9x9, 1 - 6x6, 2 - 2x2 mode at least should be st,mode. autorepeat is probably generic enough that it doesn't need the vendor prefix. Ok. -- Viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: SPEAr600: Add device-tree support to SPEAr600 boards
On Mar 27, 2012 7:07 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 27 March 2012, Viresh Kumar wrote: On 3/27/2012 4:45 PM, Arnd Bergmann wrote: On Tuesday 27 March 2012, Viresh Kumar wrote: The normal way is to turn around the logic so you don't have to include this test at all. Just have one soc-specific init_machine and map_io function, that calls both soc-specific and shared soc functions, e.g. But with that, i need multiple DT_MACHINE_START(). Isn't it? Is this advisable? Having one DT_MACHINE_START per soc is ok if it helps you. Of course if you have multiple ones that are basically identical, it's simpler to just combine them. That's what i have done in V1. And then only i came to The first problem i mentioned. In case of the clocks, I think you could already merge all the clk_lookup arrays into one, which would result in a larger kernel image but should do no harm otherwise. Actually we can't do it. :( If i boot 300 then i will also get clocks of 310 and 320 in my clock list. And once i go through this clock list to create clock tree (parent-child relationship), i will try to access hardware registers of 310 320, which are just not valid for 300. Kernel Crash!! Ok, I see. BTW, have you tried what I first recommended to you, which is to check the compatible property of the clock node instead of the machine? I haven't. Obviously that only works when you initialize the clocks from init_early() instead of from map_io(), but I think that would be the cleanest choice if you want to have single function with run-time dependencies. But then why not use machine_init() for doing this too. -- Viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: kirkwood devicetree respin
From: Felipe Balbi [mailto:ba...@ti.com] Sent: Tuesday, March 27, 2012 2:05 AM Hi, On Thu, Mar 22, 2012 at 06:28:26PM +, Paul Zimmerman wrote: context, toggle clocks, set pads in safe mode (when needed) and so on. But fair enough, both ways would work fine. I would also recommend your/Alan's approach to this over Felipe's way. We have a DWC3 platform with an (admittedly oddball) PM implementation that requires the bus driver to have some knowledge of the base driver's internal state, and needs the two drivers to be able to communicate with each other. With the base driver being a separate platform device, this is nearly impossible to achieve in a clean way. If the DWC3 driver was designed the way you and Alan are recommending, it would be easy. I'm trying to convince Felipe to change the DWC3 driver design to accommodate this, but I hold out little hope for that :) yeah, I'm not thinking on taking that patch, sorry. Didn't you say SNPS had agreed on rebuilding the FPGA system so that it's a more standard PCIe implementation ? I still owe you another possible implementation for the whole PM thing, sorry about the delay. Dropped the other folks from CC since they probably aren't interested. The FPGA rework is very low priority, those guys have more important stuff to work on at the moment. Plus management doesn't understand why the current design won't work, since the Synopsys driver supports it OK. So I'm not sure when the FPGA rework will happen. Ok, so let's work with what we have now. I'll try to shuffle your patches around to the way I think they could/should be done, but I'll need your help testing since I don't have any hibernation-enabled version of the IP at hand. Hope it's ok with you ;-) Sure. I'd like to make some progress on this. -- Paul ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: SPEAr600: Add device-tree support to SPEAr600 boards
On 3/27/2012 7:29 PM, Arnd Bergmann wrote: That would be even better. I think we should generally try do initialization as late as possible, ideally from initcalls. The init_early() function should only be used for code that absolutely has to be run from setup_arch() and no later, while the map_io() function should ideally only be used to set up the static mappings and nothing else. I remember now why we do it in map_io(). Timers need clock support and they are up before machine_init() is called. So, i believe i must have DT_MACHINE_START per SoC. I will post V2 for 3xx DT support today, but can i have initial level of review from you, so that i can fixup minor issues in V2 only? -- viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/1] ARM: imx28: add basic dt support
On Fri, Mar 23, 2012 at 10:31:10PM +0800, Dong Aisheng wrote:
From: Dong Aisheng dong.aish...@linaro.org
This patch includes basic dt support which can boot via nfs rootfs.
Signed-off-by: Dong Aisheng dong.aish...@linaro.org
---
ChangeLog v1-v2:
* Some fixes addressed Rob's review comments.
Remove using of OF_DEV_AUXDATA.
* Remove mac address from dts file
Currently we use the mac address got from uboot to work.
Will submit a p separate atch using prom_update_property to fix this
issue for driver based on suggestions from Grant and Lothar.
* rename mxs-dt.c to mach-mxs.c which is supposed to support mx23 dt
too in the future.
* add compatible string fsl,imx28 per Sascha's suggestion
* add more devices in dtsi file
For those devices still not in use, set the state to disabled
by default.
For other patches i sent with this in the first series like mmc and sdma
dt support, i will send out them separately since this patch does not depend
on them and does not block you to run dt via nfs rootfs.
---
Documentation/devicetree/bindings/arm/fsl.txt |4 +
arch/arm/boot/dts/imx28-evk.dts | 35 +++
arch/arm/boot/dts/imx28.dtsi | 358
+
arch/arm/mach-mxs/Kconfig |8 +
arch/arm/mach-mxs/Makefile|1 +
arch/arm/mach-mxs/clock-mx28.c|4 +
arch/arm/mach-mxs/mach-mxs.c | 69 +
7 files changed, 479 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/imx28-evk.dts
create mode 100644 arch/arm/boot/dts/imx28.dtsi
create mode 100644 arch/arm/mach-mxs/mach-mxs.c
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt
b/Documentation/devicetree/bindings/arm/fsl.txt
index 54bddda..9f21faf 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -1,6 +1,10 @@
Freescale i.MX Platforms Device Tree Bindings
---
+i.MX28 Evaluation Kit
+Required root node properties:
+- compatible = fsl,imx28-evk, fsl,imx28;
+
i.MX51 Babbage Board
Required root node properties:
- compatible = fsl,imx51-babbage, fsl,imx51;
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
new file mode 100644
index 000..5402495
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -0,0 +1,35 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ imx28.dtsi
+
+/ {
+ model = Freescale i.MX28 Evaluation Kit;
+ compatible = fsl,imx28-evk, fsl,imx28;
+
+ memory {
+ device_type = memory;
This is already in skeleton.dtsi included by imx28.dtsi.
+ reg = 0x4000 0x0800;
+ };
+
+ ahb@8008 {
+ ethernet@800f {
+ phy-mode = rmii;
+ status = okay;
+ };
+
+ ethernet@800f4000 {
+ phy-mode = rmii;
+ status = okay;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
new file mode 100644
index 000..9152354
--- /dev/null
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -0,0 +1,358 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/include/ skeleton.dtsi
+
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
These two are already in skeleton.dtsi.
+ interrupt-parent = icoll;
+
+ aliases {
+ serial0 = duart;
+ };
+
+ cpus {
+ cpu@0 {
+ compatible = arm,arm926ejs;
+ };
+ };
+
+ apb@8000 {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x8000 0x8;
+ ranges;
+
+ apbh@8000 {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x8000 0x3c900;
+ ranges;
+
+ icoll: interrupt-controller@8000 {
+ compatible = fsl,imx28-icoll;
I would expect it be:
compatible = fsl,imx28-icoll,
