Hi!
Changes since v1:
- renamed patches
- reworked commit messages
- squashed patches
- added missing SOB
- match on rtc nodename instead of using a new binding
- general cleanup
I did not rework the sysfs stuff, as I'm still not sure if this
is
If an alarm is set and the system rebooted, the alarm does not get re-enabled,
although it may still be valid (i.e. in the future).
The sysfs representation of wakealarms prevents overwriting active alarms. One
needs to instead write a 0 first and then the new value. Therefore an alarm is
On 02/14/2013 10:59 PM, Joachim Eastwood :
Signed-off-by: Joachim Eastwood manab...@gmail.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Alessandro, do you want to queue this one on your side?
Best regards,
---
.../devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt | 15
On 02/14/2013 06:42 PM, Joachim Eastwood :
Hi
This series clean up at91_cf a bit and add DT bindings.
Patch series tested on custom RM9200 board in both with DT and
with old platform data.
Joachim Eastwood (5):
pcmcia: at91_cf: fix gpio_get_value in at91_cf_get_status
pcmcia:
Sekhar,
On Mon, Feb 4, 2013 at 11:20 PM, Sekhar Nori nsek...@ti.com wrote:
On 2/4/2013 10:37 AM, Prabhakar Lad wrote:
Sekhar ,
On Sun, Feb 3, 2013 at 5:33 PM, Sekhar Nori nsek...@ti.com wrote:
On 1/28/2013 7:17 PM, Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar@ti.com
Add eth0
On 3/8/2013 3:15 PM, Prabhakar Lad wrote:
Sekhar,
On Mon, Feb 4, 2013 at 11:20 PM, Sekhar Nori nsek...@ti.com wrote:
On 2/4/2013 10:37 AM, Prabhakar Lad wrote:
Sekhar ,
On Sun, Feb 3, 2013 at 5:33 PM, Sekhar Nori nsek...@ti.com wrote:
On 1/28/2013 7:17 PM, Prabhakar Lad wrote:
From: Lad,
On 02/04/2013 04:58 PM, Roger Quadros wrote:
The PHY clock, clock rate, VCC regulator and RESET regulator
can now be provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt | 34
Sekhar,
On Mon, Feb 4, 2013 at 10:33 AM, Prabhakar Lad
prabhakar.cse...@gmail.com wrote:
Sekhar ,
On Sun, Feb 3, 2013 at 6:15 PM, Sekhar Nori nsek...@ti.com wrote:
On 1/28/2013 7:17 PM, Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar@ti.com
The system configuration chip CFGCHIP3,
On Fri, 2013-03-08 at 12:53 +0530, Mugunthan V N wrote:
On 3/8/2013 1:29 AM, Ben Hutchings wrote:
On Thu, 2013-03-07 at 14:24 +0100, Peter Korsgaard wrote:
M == Mugunthan V N mugunthan...@ti.com writes:
M This patch implements get/set of the phy settings via ethtool apis
M
Ben == Ben Hutchings bhutchi...@solarflare.com writes:
Hi,
Ben The 'active slave' property would also be needed for the SIOCGMIIPHY
Ben ioctl and not just ethtool. But it's really quite arbitrary. Perhaps
Ben each of them should have their own net device (as with DSA).
Indeed, I think
On 03/08/2013 12:46 PM, Marc Kleine-Budde wrote:
On 02/04/2013 04:58 PM, Roger Quadros wrote:
The PHY clock, clock rate, VCC regulator and RESET regulator
can now be provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt
On 3/8/2013 8:23 PM, Ben Hutchings wrote:
On Fri, 2013-03-08 at 12:53 +0530, Mugunthan V N wrote:
On 3/8/2013 1:29 AM, Ben Hutchings wrote:
On Thu, 2013-03-07 at 14:24 +0100, Peter Korsgaard wrote:
M == Mugunthan V N mugunthan...@ti.com writes:
M This patch implements get/set of the phy
On 3/8/2013 8:34 PM, Peter Korsgaard wrote:
Ben == Ben Hutchings bhutchi...@solarflare.com writes:
Hi,
Ben The 'active slave' property would also be needed for the SIOCGMIIPHY
Ben ioctl and not just ethtool. But it's really quite arbitrary. Perhaps
Ben each of them should have their
On 03/08/2013 11:46 AM, Marc Kleine-Budde wrote:
On 02/04/2013 04:58 PM, Roger Quadros wrote:
The PHY clock, clock rate, VCC regulator and RESET regulator
can now be provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt
On Fri, Mar 01, 2013 at 03:13:34PM +, Rob Herring wrote:
On 03/01/2013 06:23 AM, Andrew Murray wrote:
This patch factors out common implementations patterns to reduce overall
kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's
Hi All,
Here is an updated version of my patch series adding device tree support
for the Samsung S5P/Exynos SoC series camera subsystem. Previous version
can be found at [1]. Still it doesn't include asynchronous subdev
registration support as I have been focused on the Exynos4x12 SoC camera
Hi All,
Here is an updated version of my patch series adding device tree support
for the Samsung S5P/Exynos SoC series camera subsystem. Previous version
can be found at [1]. Still it doesn't include asynchronous subdev
registration support as I have been focused on the Exynos4x12 SoC camera
This patch support for binding the driver to the MIPI-CSIS
devices instantiated from device tree and parsing the SoC
and board specific properties. The MIPI CSI-2 channel is
determined by the value of reg property placed in csis'
port subnode.
Signed-off-by: Sylwester Nawrocki
This patch adds device tree support for FIMC driver on S5PV210 and
Exynos4 SoCs.
The FIMC IP block's features and quirks encoded statically in
the driver are now parsed from the device tree. Once all relevant
platforms are converted to device tree based booting the FIMC
variant data structures
This patch adds the device tree support for FIMC-LITE device
driver. The bindings include compatible property for the Exynos5
SoC series, however the actual implementation for these SoCs will
be added in a separate patch.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by:
This patch adds changes required for the main camera media device
driver corresponding to the top level 'camera' device node.
The drivers of devices corresponding to child nodes of the 'camera'
node are looked up and and registered as sub-devices to the top
level driver. The main driver's probing
The sensor (I2C and/or SPI client) devices are instantiated by their
corresponding control bus drivers. Since the I2C client's master clock
is often provided by a video bus receiver (host interface) or other
than I2C/SPI controller device, the drivers of those client devices
are not accessing
Before the camera ports can be used the pinmux needs to be configured
properly. This patch adds a function to set the camera ports pinctrl
to a default state within the media driver's probe().
The camera port(s) are then configured for the video bus operation.
Signed-off-by: Sylwester Nawrocki
The OMAP2+ code that configures the GPMC for ONENAND devices is copying
structures between functions unnecessarily. Avoid this by passing
pointers instead and simplify the code.
A pointer to structure omap_onenand_platform_data is passed to the
function omap2_onenand_calc_sync_timings(), but only
The GPMC has wait-pin signals that can be assigned to a chip-select
to monitor the ready signal of an external device. Add a variable to
indicate the total number of wait-pins for a given device. This will
allow us to detect if the wait-pin being selected is valid or not.
When booting with
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no central structure for storing all these options
when configuring the GPMC for a given device. Some of the options are
stored in the GPMC
While adding device-tree support for NOR memories, it became apparent
that there is no common way for configuring various GPMC settings for
devices that interface to the GPMC. These settings include bus-width,
synchronous/asynchronous mode, burst settings, wait monitoring etc.
Therefore, to
Convert the OMAP2+ SMC91x code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Move configuration of the GPMC settings outside retime function and
this does not need to be done if the timings are changed
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no common function for configuring these options and
various devices set these options by either programming the GPMC CONFIG1
register
Convert the OMAP2+ TUSB code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/usb-tusb6010.c | 43
Convert the OMAP2+ NAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
This moves the configuration of some GPMC options outside the
nand_gpmc_retime() because these options should only need to be
When booting with device-tree, retrieve GPMC settings for NAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Each GPMC chip-select can be configured to map 16MB, 32MB, 64MB or 128MB
of address space. The physical base address where a chip-select starts
is also configurable and must be aligned on a boundary that is equal to
or greater than the size of the address space mapped bt the chip-select.
When
With the addition of the gpmc_cs_program_settings(), we no longer need
or use gpmc_cs_configure() to configure some of the GPMC chip-select
options. So rename the function to gpmc_configure() and remove code that
modifies options in the CONFIG1 register.
Signed-off-by: Jon Hunter
NOR flash is not currently supported when booting with device-tree
on OMAP2+ devices. Add support to detect and configure NOR devices
when booting with device-tree.
Add documentation for the TI GPMC NOR binding.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
When booting with device-tree, retrieve GPMC settings for ONENAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.
The user must now specify the ONENAND device width in the
When the GPMC driver is probed, we call gpmc_mem_init() to see which
chip-selects have already been configured and enabled by the boot-loader
and allocate space for them. If we fail to allocate space for one
chip-select, then we return failure from the probe and the GPMC driver
will not be
With commit 21cc2bd (ARM: OMAP2+: Remove apollon board support) the
variable boot_rom_space is now not needed and the code surrounding
this variable can be cleaned up and simplified. Remove unnecessary
definitions and clean-up the comment as well.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Some of the GPMC timings parameters are currently missing from the GPMC
device-tree binding. Add these parameters to the binding documentation
as well as code to read them.
The existing code in gpmc_read_timings_dt() is checking the value of
of_property_read_u32() and only is successful storing
On Fri, Mar 08, 2013 at 08:14:44AM +0100, Thierry Reding wrote:
On Thu, Mar 07, 2013 at 06:05:33PM -0600, Rob Herring wrote:
On 03/07/2013 02:47 PM, Thierry Reding wrote:
[...]
In a nutshell (since some of the context isn't quoted anymore) the
problem that we're trying to solve is that
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent before
individually but re-sending here as a complete series for v3.10.
This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian
Vaussard [1] and OMAP5 DT
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface
Adds basic device-tree support for OMAP3430 SDP board which has 256MB
of RAM and uses the TWL4030 power management IC.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3430-sdp.dts | 46
2
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430. The node for OMAP4430 is not included because PMU is not
currently supported on OMAP4430 due to the
Add the device-tree nodes for the 128MB ONENAND flash and 256MB NAND
flash memories found on the OMAP3430 SDP board.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap3430-sdp.dts | 95
1 file changed, 95 insertions(+)
diff --git
Add gpios bindings for OMAP2420 and OMAP2430 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 44 +++
arch/arm/boot/dts/omap2430.dtsi | 55 +++
2 files changed, 99 insertions(+)
diff
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC periperhal on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter
The OMAP3 gpio bindings are currently missing the reg and interrupt
properties and so add these properties.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi
The OMAP gpio binding documention [1] states that the #interrupts-cells
property for gpio controllers should be 2. Currently, for OMAP3+ devices
the #interrupt-cells is set to 1. By setting this property to 2, it
allows clients to pass a 2nd parameter indicating the sensitivity (level
or edge) and
From: Ludovic Desroches ludovic.desroc...@atmel.com
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
---
drivers/net/can/at91_can.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
index c7f70d4..56fb2aa 100644
---
From: Ludovic Desroches ludovic.desroc...@atmel.com
SAMA5D3 devices also embed CAN feature. Moreover if we want to produce a single
kernel image (at least for Atmel devices) it is not useful to be too
restrictive.
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
---
On 03/08/2013 06:30 PM, ludovic.desroc...@atmel.com wrote:
From: Ludovic Desroches ludovic.desroc...@atmel.com
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
---
drivers/net/can/at91_can.c | 9 +
1 file changed, 9 insertions(+)
diff --git
On 03/08/2013 06:30 PM, ludovic.desroc...@atmel.com wrote:
From: Ludovic Desroches ludovic.desroc...@atmel.com
Add device tree support.
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
---
.../devicetree/bindings/net/can/atmel-can.txt | 14
On 03/08/2013 06:30 PM, ludovic.desroc...@atmel.com wrote:
From: Ludovic Desroches ludovic.desroc...@atmel.com
SAMA5D3 devices also embed CAN feature. Moreover if we want to produce a
single
kernel image (at least for Atmel devices) it is not useful to be too
restrictive.
If it compiles
On 03/08/2013 06:38 PM, Sören Brinkmann wrote:
On Fri, Mar 08, 2013 at 08:12:20AM +0100, Lars-Peter Clausen wrote:
On 03/08/2013 12:25 AM, Sören Brinkmann wrote:
On Thu, Mar 07, 2013 at 11:02:58PM +0100, Lars-Peter Clausen wrote:
On 03/07/2013 08:11 PM, Sören Brinkmann wrote:
On Thu, Mar 07,
On Fri, Mar 08, 2013 at 09:52:28AM -0700, Jason Gunthorpe wrote:
On Fri, Mar 08, 2013 at 08:14:44AM +0100, Thierry Reding wrote:
On Thu, Mar 07, 2013 at 06:05:33PM -0600, Rob Herring wrote:
On 03/07/2013 02:47 PM, Thierry Reding wrote:
[...]
In a nutshell (since some of the context
On 18:37 Fri 08 Mar , Marc Kleine-Budde wrote:
On 03/08/2013 06:30 PM, ludovic.desroc...@atmel.com wrote:
From: Ludovic Desroches ludovic.desroc...@atmel.com
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
---
drivers/net/can/at91_can.c | 9 +
1 file
On 3/8/2013 9:12 AM, Thierry Reding wrote:
On Fri, Mar 08, 2013 at 09:52:28AM -0700, Jason Gunthorpe wrote:
On Fri, Mar 08, 2013 at 08:14:44AM +0100, Thierry Reding wrote:
On Thu, Mar 07, 2013 at 06:05:33PM -0600, Rob Herring wrote:
On 03/07/2013 02:47 PM, Thierry Reding wrote:
[...]
In a
On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
http://www.spinics.net/lists/arm-kernel/msg228749.html
The example in that posting looks messed up to me.
1) It has reg = 0x0800 0 0 0 0, but 0x0800 0 0 is not a valid
address in the address space defined by its parent -
On Fri, Mar 08, 2013 at 01:02:46PM -0700, Jason Gunthorpe wrote:
On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
[...]
2) The @0,0 and @1,0 suffixes do not correspond to the reg values
0x0800 0 0 0 0 and 0x1000 0 0 0 0 using any rule that I know.
@0,1,0 (bus,device,fn) could
On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter jon-hun...@ti.com wrote:
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 11 +++
arch/arm/boot/dts/omap2430.dtsi | 11 +++
On 03/08/2013 02:25 PM, Javier Martinez Canillas wrote:
On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter jon-hun...@ti.com wrote:
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 11
On 03/08/2013 01:14 AM, Thierry Reding wrote:
On Thu, Mar 07, 2013 at 06:05:33PM -0600, Rob Herring wrote:
On 03/07/2013 02:47 PM, Thierry Reding wrote:
[...]
In a nutshell (since some of the context isn't quoted anymore) the
problem that we're trying to solve is that some of the embedded
On 3/8/2013 10:02 AM, Jason Gunthorpe wrote:
On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
http://www.spinics.net/lists/arm-kernel/msg228749.html
The example in that posting looks messed up to me.
1) It has reg = 0x0800 0 0 0 0, but 0x0800 0 0 is not a valid
address in
On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote:
On 03/08/2013 02:25 PM, Javier Martinez Canillas wrote:
On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter jon-hun...@ti.com wrote:
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter
On Fri, Mar 08, 2013 at 01:46:13PM -1000, Mitch Bradley wrote:
On 3/8/2013 10:02 AM, Jason Gunthorpe wrote:
On Fri, Mar 08, 2013 at 09:43:11AM -1000, Mitch Bradley wrote:
http://www.spinics.net/lists/arm-kernel/msg228749.html
The example in that posting looks messed up to me.
1) It
Hi Jon,
On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter jon-hun...@ti.com wrote:
Adds basic device-tree support for OMAP3430 SDP board which has 256MB
of RAM and uses the TWL4030 power management IC.
I think this board support should be in separate patch series with
related patches.
On 8 March 2013 14:11, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
Also in your driver you're doing
cpufreq_notify_transition(freqs, CPUFREQ_PRECHANGE);
...
cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
So, theoretically you
On Fri, Mar 8, 2013 at 5:58 PM, Jon Hunter jon-hun...@ti.com wrote:
NOR flash is not currently supported when booting with device-tree
on OMAP2+ devices. Add support to detect and configure NOR devices
when booting with device-tree.
Add documentation for the TI GPMC NOR binding.
69 matches
Mail list logo
