On Sep 15, 2011, at 1:04 PM, Timur Tabi wrote:
> Standarize and document the FPGA nodes used on Freescale QorIQ reference
> boards. There are different kinds of FPGAs used on the boards, but
> only two are currently standard: "pixis", "ngpixis", and "qixis". Although
> there are minor differenc
Add device tree bindings so that the gpio-nand driver may be
instantiated from the device tree. This also allows the partitions
to be specified in the device tree.
v6: - convert to mtd_device_parse_register()
v5: - fold dt config helpers into a single gpio_nand_of_get_config()
v4: - g
Signed-off-by: Stephen Warren
---
arch/arm/mach-tegra/pinmux.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-tegra/pinmux.c b/arch/arm/mach-tegra/pinmux.c
index f80d507..46b9d87 100644
--- a/arch/arm/mach-tegra/pinmux.c
+++ b/arch
v3: Make regs variable static. Remove empty init of tegra_gpio_banks.
v2: Retrieve IRQ and memory addresses from resources instead of hard-
coding them. Add back initialization of tegra_gpio_chip.of_node.
Signed-off-by: Stephen Warren
gpio fixup
---
drivers/gpio/gpio-tegra.c | 143 +++
The Tegra GPIO driver will be converted from static registration via
postcore_initcall() to be a platform device later in this patch series.
A new Tegra pinmux platform device will also be added.
Prepare for this by modifying all boards to register the appropriate
platform devices before-hand, so
Add a pinmux node to tegra20.dtsi in order to instantiate the future
pinmux device.
v2: Specify reg property precisely; don't just point at the whole APB_MISC
register range.
Signed-off-by: Stephen Warren
---
.../devicetree/bindings/pinmux/pinmux_nvidia.txt |5 +
arch/arm/boot/dts/teg
On Tue, Oct 11, 2011 at 2:29 PM, Olof Johansson wrote:
>> @@ -333,28 +336,55 @@ static struct irq_chip tegra_gpio_irq_chip = {
>> */
>> static struct lock_class_key gpio_lock_class;
>>
>> -static int __init tegra_gpio_init(void)
>> +static int __init tegra_gpio_probe(struct platform_device *pde
Hi,
Some nits below. Overall looks good.
On Tue, Oct 11, 2011 at 02:23:57PM -0600, Stephen Warren wrote:
> @@ -76,16 +75,20 @@ struct tegra_gpio_bank {
> };
>
>
> -static struct tegra_gpio_bank tegra_gpio_banks[] = {
> - {.bank = 0, .irq = INT_GPIO1},
> - {.bank = 1, .irq = INT_GPIO2
v2: Retrieve IRQ and memory addresses from resources instead of hard-
coding them. Add back initialization of tegra_gpio_chip.of_node.
Signed-off-by: Stephen Warren
---
drivers/gpio/gpio-tegra.c | 142 ++---
1 files changed, 95 insertions(+), 47 deletions
The Tegra GPIO driver will be converted from static registration via
postcore_initcall() to be a platform device later in this patch series.
A new Tegra pinmux platform device will also be added.
Prepare for this by modifying all boards to register the appropriate
platform devices before-hand, so
Add a pinmux node to tegra20.dtsi in order to instantiate the future
pinmux device.
v2: Specify reg property precisely; don't just point at the whole APB_MISC
register range.
Signed-off-by: Stephen Warren
---
.../devicetree/bindings/pinmux/pinmux_nvidia.txt |5 +
arch/arm/boot/dts/teg
v2: Convert GPIO driver to ioremap its registers instead of using static
mappings. The pinmux driver doesn't do this yet, but will soon. However,
the pinmux register resources/DT-properties are set up correctly for when
the driver is converted. Also, add back initialization of
tegra_gpio_chip.of_no
Signed-off-by: Stephen Warren
---
arch/arm/mach-tegra/pinmux.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-tegra/pinmux.c b/arch/arm/mach-tegra/pinmux.c
index f80d507..46b9d87 100644
--- a/arch/arm/mach-tegra/pinmux.c
+++ b/arch
On Tuesday 11 October 2011 19:28:06 Nicolas Ferre wrote:
>
> > +Optional properties:
> > +- linux,rs485-enabled-at-boot-time: empty property telling to enable the
> > rs485
> > + feature at boot time. It can be disabled later with proper ioctl.
>
> +- linux,rs485-rx-during-tx: empty property th
On Tue, Oct 11, 2011 at 11:01 AM, Jon Loeliger wrote:
>> This patch set adds, tests, and documents support for variable sized
>> elements in
>> arrays (known as cell lists when they could only support 32-bit entries).
>> The
>> new syntax is:
>>
>> property = /bits/ [8|16|32|64] <0x00
On 11 October 2011 21:59, Stephen Warren wrote:
> Thomas Abraham wrote at Sunday, October 09, 2011 12:58 AM:
>> On 5 October 2011 21:25, Stephen Warren wrote:
>> > Thomas Abraham wrote at Wednesday, October 05, 2011 8:28 AM:
>> >> On 5 October 2011 18:59, Rob Herring wrote:
>> >> > On 10/05/2011
> This patch set adds, tests, and documents support for variable sized elements
> in
> arrays (known as cell lists when they could only support 32-bit entries). The
> new syntax is:
>
> property = /bits/ [8|16|32|64] <0x00 0x12>;
>
> So arrays of 8, 16, 32, or 64-bit elements can now b
I can also add this new property (support for it already in linux-next):
On 10/11/2011 07:13 PM, Nicolas Ferre :
> Generic bindings for RS485 feature included in some UARTs.
> Those bindings have to be used withing an UART device tree node.
> Documentation updated to link to the bindings definitio
Elements of size 8, 16, 32, and 64 bits are supported. The new
/bits/ syntax was selected so as to not pollute the reserved
keyword space with uint8/uint16/... type names.
With this patch the following property assignment:
property = /bits/ 16 <0x1234 0x5678 0x0 0x>;
is equivalent to:
This function deals with appending integers of various sizes (8, 16
32, and 64 bit currently). It handles endianess conversions. If the
integer will not fit in the requested number of bits of storage it
will have it's high bits ignored.
This patch also rewrites data_append_cell and data_append_a
This utility routine will be used in the variable size cell literal
append code. It is a straightforward adaptation of the fdt32_to_cpu
function.
Signed-off-by: Anton Staaf
Acked-by: David Gibson
Cc: Jon Loeliger
Cc: David Gibson
Cc: Grant Likely
---
libfdt/libfdt_env.h |6 ++
1 fil
This patch set adds, tests, and documents support for variable sized elements in
arrays (known as cell lists when they could only support 32-bit entries). The
new syntax is:
property = /bits/ [8|16|32|64] <0x00 0x12>;
So arrays of 8, 16, 32, or 64-bit elements can now be created. No pa
On Tue, Oct 11, 2011 at 8:22 AM, Jon Loeliger wrote:
>> >>
>> >> Signed-off-by: Anton Staaf
>> >
>> > What the hell, I think I've convinced myself that /bits/ is good
>> > enough.
>>
>> Thanks David, I haven't thought of anything more appropriate either.
>> I'm looking forward to getting this lan
Generic bindings for RS485 feature included in some UARTs.
Those bindings have to be used withing an UART device tree node.
Documentation updated to link to the bindings definition.
Signed-off-by: Nicolas Ferre
---
Hi all,
1/ I have used the "linux" vendor definition: tell me if it makes sense..
Thomas Abraham wrote at Sunday, October 09, 2011 12:58 AM:
> On 5 October 2011 21:25, Stephen Warren wrote:
> > Thomas Abraham wrote at Wednesday, October 05, 2011 8:28 AM:
> >> On 5 October 2011 18:59, Rob Herring wrote:
> >> > On 10/05/2011 05:13 AM, Thomas Abraham wrote:
> >> >> Device nodes r
On 11 October 2011 21:00, Rob Herring wrote:
> On 10/11/2011 10:19 AM, Thomas Abraham wrote:
>> Hi Rob,
>>
>> On 11 October 2011 20:41, Rob Herring wrote:
>>> Thomas,
>>>
>>> On 10/11/2011 03:16 AM, Thomas Abraham wrote:
As gpio chips get registered, a device tree node which represents the
>
On 10/04/2011 06:55 PM, Grant Likely :
> On Tue, Oct 04, 2011 at 08:08:27AM -0500, Rob Herring wrote:
>> Nicolas,
>>
>> On 10/04/2011 03:18 AM, Nicolas Ferre wrote:
>>> On 10/04/2011 03:58 AM, Rob Herring :
On 10/03/2011 04:51 AM, Nicolas Ferre wrote:
> +Optional properties:
> +- atmel
On 10/11/2011 10:19 AM, Thomas Abraham wrote:
> Hi Rob,
>
> On 11 October 2011 20:41, Rob Herring wrote:
>> Thomas,
>>
>> On 10/11/2011 03:16 AM, Thomas Abraham wrote:
>>> As gpio chips get registered, a device tree node which represents the
>>> gpio chip is searched and attached to it. A transla
> >>
> >> Signed-off-by: Anton Staaf
> >
> > What the hell, I think I've convinced myself that /bits/ is good
> > enough.
>
> Thanks David, I haven't thought of anything more appropriate either.
> I'm looking forward to getting this landed. :)
To facilitate that, could you post current patch se
Hi Rob,
On 11 October 2011 20:41, Rob Herring wrote:
> Thomas,
>
> On 10/11/2011 03:16 AM, Thomas Abraham wrote:
>> As gpio chips get registered, a device tree node which represents the
>> gpio chip is searched and attached to it. A translate function is also
>> provided to convert the gpio speci
On Tue, Oct 11, 2011 at 7:44 AM, David Gibson
wrote:
> On Tue, Sep 27, 2011 at 11:11:38AM -0700, Anton Staaf wrote:
>> Elements of size 8, 16, 32, and 64 bits are supported. The new
>> /bits/ syntax was selected so as to not pollute the reserved
>> keyword space with uint8/uint16/... type names.
Thomas,
On 10/11/2011 03:16 AM, Thomas Abraham wrote:
> As gpio chips get registered, a device tree node which represents the
> gpio chip is searched and attached to it. A translate function is also
> provided to convert the gpio specifier into actual platform settings
> for pin function selection
Hi Vinod,
On 11 October 2011 17:36, Kukjin Kim wrote:
> Thomas Abraham wrote:
>>
>> Changes since v5:
>> - Added alias clocks for pdma clocks on Exynos4.
>> - Modified platform data for s5p64x0, s5pc100 and s5pv210.
>> - Rebased on the tip of for-next branch of linux-samsung kernel and
> tested.
On Tue, Sep 27, 2011 at 11:11:38AM -0700, Anton Staaf wrote:
> Elements of size 8, 16, 32, and 64 bits are supported. The new
> /bits/ syntax was selected so as to not pollute the reserved
> keyword space with uint8/uint16/... type names.
>
> With this patch the following property assignment:
>
On Tue, Sep 27, 2011 at 11:11:37AM -0700, Anton Staaf wrote:
> This function deals with appending integers of various sizes (8, 16
> 32, and 64 bit currently). It handles endianess conversions. If the
> integer will not fit in the requested number of bits of storage it
> will have it's high bits
On Tue, Sep 27, 2011 at 11:11:36AM -0700, Anton Staaf wrote:
> This utility routine will be used in the variable size cell literal
> append code. It is a straightforward adaptation of the fdt32_to_cpu
> function.
>
> Signed-off-by: Anton Staaf
Acked-by: David Gibson
--
David Gibson
On Mon, 2011-10-10 at 18:37 +0200, Nicolas Ferre wrote:
> DMA controller can deduce its configuration data from
> the platform. Remove the platform data and match device
> types with the compatible ones.
This looks like remove, you should fix the changelog of patch 1 then.
>
> Signed-off-by: Nicol
On Mon, 2011-10-10 at 18:37 +0200, Nicolas Ferre wrote:
> We remove platform data from DMA controller and move
> to the use of .id_table to distinguish between compatible
> types. The two implementations allow to determine the
> number of channels and the capabilities of the controller.
>
> Signed
Add initial dts file for Exynos4210 SoC. This dts file describes the SoC
specific devices and properties. Along with this, add dts file for Samsung's
SMDKV310 board and Insignal's Origen board which uses the Exynos4210 dts file
and extends it to describe the board specific properties.
Signed-off-b
Add a new Exynos4 compatible device tree enabled board file. Boards based on
the Exynos4 family of SoC's can use this as the machine/board file. When using
this machine fike, a corresponding device tree blob which describes the board's
properties should be supplied at boot time to the kernel.
Sign
This patchset adds a new basic device tree enabled machine/board file which is
based on the Samsung's Exynos4 family of SoC's. Also included in this patchset
is the
dts file for Exynos4210 SoC, Samsung's SMDKV310 board and Insignal's Origen
board.
The Exynos4210 dts file includes support for IRQ
Thomas Abraham wrote:
>
> Changes since v4:
> - Tested with linux 3.1-rc9. No changes in code.
>
> Changes since v3:
> - Addressed comments from Grant Likely.
> - Set num_rows and num_cols to zero in samsung_keypad_parse_dt function.
> - Fixed the wierd looking if-else block in samsung_keypad
Hello.
On 10-10-2011 20:43, Nicolas Ferre wrote:
Device tree support on at91sam9g45 family SoC. Only call
platform_device_register() if no compatible dma-controller
node is found in device tree.
Signed-off-by: Nicolas Ferre
---
V2: use compatible string to match device.
[...]
diff --git
Thomas Abraham wrote:
>
> On 3 September 2011 21:19, Thomas Abraham
> wrote:
> > Add device tree based discovery support for Samsung's rtc controller.
> >
> > Cc: Ben Dooks
> > Signed-off-by: Thomas Abraham
> > ---
> > Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 20
>
As gpio chips get registered, a device tree node which represents the
gpio chip is searched and attached to it. A translate function is also
provided to convert the gpio specifier into actual platform settings
for pin function selection, pull up/down and driver strength settings.
Signed-off-by: Th
>
>> + if (supply) {
>> + struct regulator_dev *r;
>> + struct device_node *node;
>> +
>> + /* first do a dt based lookup */
>> + if (dev) {
>> + node = of_get_regulator(dev, supply);
>> + if (node)
>> +
On 3 September 2011 21:19, Thomas Abraham wrote:
> Add device tree based discovery support for Samsung's rtc controller.
>
> Cc: Ben Dooks
> Signed-off-by: Thomas Abraham
> ---
> Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 20
> drivers/rtc/rtc-s3c.c
47 matches
Mail list logo
