On Thu, Aug 02, 2012 at 18:43:11, AnilKumar, Chimata wrote:
> Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
> APIs control clocks for C_CAN/D_CAN IP and prevent access to the
> register of C_CAN/D_CAN IP when clock is turned off.
>
> Signed-off-by: AnilKumar Ch
> ---
> drivers
On 7/25/2012 5:53 PM, AnilKumar Ch wrote:
> Add Bosch D_CAN controller device tree data to AM33XX dtsi file
> by adding d_can device node with all the necessary parameters.
>
> Signed-off-by: AnilKumar Ch
> ---
> arch/arm/boot/dts/am33xx.dtsi |5 +
> 1 file changed, 5 insertions(+)
>
On Tue, Jun 12, 2012 at 05:10:20PM -0600, Stephen Warren wrote:
> From: Stephen Warren
>
> dtc currently allows the contents of properties to be changed, and the
> contents of nodes to be added to. There are situations where removing
> properties or nodes may be useful. This change implements the
On Fri, Aug 03, 2012 at 10:52:40, Daniel Mack wrote:
> On 03.08.2012 07:16, Vaibhav Hiremath wrote:
> >
> >
> > On 8/3/2012 1:13 AM, Daniel Mack wrote:
> >> Make the driver control the device clocks. Appearantly, the Davinci
> >> platform probes this driver with the clock all powered up, but on O
On 08/02/2012 09:39 PM, Leela Krishna Amudala wrote:
> Hello,
>
> Can some one please tell me how to read the args from the gpio handle
>
> For example:
> Considerlcd-reset-gpio = <&gpx0 1 2 3 4>; as my phandle.
>
> The 4 args in the above handle denotes
>
> <[phandle of the gpio controller
On 03.08.2012 07:16, Vaibhav Hiremath wrote:
>
>
> On 8/3/2012 1:13 AM, Daniel Mack wrote:
>> Make the driver control the device clocks. Appearantly, the Davinci
>> platform probes this driver with the clock all powered up, but on OMAP,
>> this isn't the case.
>>
>> Signed-off-by: Daniel Mack
>>
On 8/3/2012 1:13 AM, Daniel Mack wrote:
> Make the driver control the device clocks. Appearantly, the Davinci
> platform probes this driver with the clock all powered up, but on OMAP,
> this isn't the case.
>
> Signed-off-by: Daniel Mack
> ---
> drivers/net/ethernet/ti/davinci_mdio.c | 16
Hi,
On 03.08.2012 05:39, Leela Krishna Amudala wrote:
> Can some one please tell me how to read the args from the gpio handle
>
> For example:
> Considerlcd-reset-gpio = <&gpx0 1 2 3 4>; as my phandle.
>
> The 4 args in the above handle denotes
>
> <[phandle of the gpio controller node]
>
Hello,
Can some one please tell me how to read the args from the gpio handle
For example:
Considerlcd-reset-gpio = <&gpx0 1 2 3 4>; as my phandle.
The 4 args in the above handle denotes
<[phandle of the gpio controller node]
[pin number within the gpio controller]
[mux function]
On 08/02/2012 06:33 PM, Olof Johansson wrote:
> On Wed, Aug 1, 2012 at 12:03 PM, Sylwester Nawrocki
> wrote:
>
>> It wouldn't be clear what specific SoCs the "samsung,exynos5-gsc" compatible
>> string applies to, would it ? I believe there are already minor differences
>> in GScaler parameters o
On Thursday 02 August 2012, Daniel Mack wrote:
> currently, all devices in arch/arm/boot/dts/am33xx.dtsi are enabled by
> default. However, depending on the actual board dts, only some of the
> devices should actually be initialized, given that they only make sense
> if their pins are actually wire
Hi,
currently, all devices in arch/arm/boot/dts/am33xx.dtsi are enabled by
default. However, depending on the actual board dts, only some of the
devices should actually be initialized, given that they only make sense
if their pins are actually wired on the board.
On other platform, such devices a
Hi Ravi,
On 02.08.2012 14:12, Ravi Babu wrote:
> This series of patches adds,
> a) Multi instances support in musb driver
> b) DT support for musb_dsps glue layer
> c) DT support for NOP transceiver
>
> AM33xx and TI81xx has dual musb controller and has two usb PHY of same type.
> This patch seri
On 02.08.2012 22:20, Paul Walmsley wrote:
> Hi
>
> On Thu, 2 Aug 2012, Daniel Mack wrote:
>
>> Make the driver control the device clocks. Appearantly, the Davinci
>> platform probes this driver with the clock all powered up, but on OMAP,
>> this isn't the case.
>>
>> Signed-off-by: Daniel Mack
>
Hi
On Thu, 2 Aug 2012, Daniel Mack wrote:
> Make the driver control the device clocks. Appearantly, the Davinci
> platform probes this driver with the clock all powered up, but on OMAP,
> this isn't the case.
>
> Signed-off-by: Daniel Mack
> ---
> drivers/net/ethernet/ti/davinci_mdio.c | 16 +
On 02.08.2012 21:53, Russell King - ARM Linux wrote:
> On Thu, Aug 02, 2012 at 09:43:35PM +0200, Daniel Mack wrote:
>> Make the driver control the device clocks. Appearantly, the Davinci
>> platform probes this driver with the clock all powered up, but on OMAP,
>> this isn't the case.
>
> Hmm, thi
On Thu, Aug 02, 2012 at 09:43:35PM +0200, Daniel Mack wrote:
> Make the driver control the device clocks. Appearantly, the Davinci
> platform probes this driver with the clock all powered up, but on OMAP,
> this isn't the case.
Hmm, this looks like it could do with improvement, especially as we're
On 07/05/2012 08:51 AM, Rob Herring wrote:
> On 07/04/2012 02:56 AM, Sascha Hauer wrote:
>> This patch adds a helper function for parsing videomodes from the devicetree.
>> The videomode can be either converted to a struct drm_display_mode or a
>> struct fb_videomode.
>> diff --git a/Documentation
Signed-off-by: Daniel Mack
---
.../devicetree/bindings/net/davinci_mdio.txt | 24 +
drivers/net/ethernet/ti/davinci_mdio.c | 39 ++
2 files changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/davinci_mdio.txt
diff
Make the driver control the device clocks. Appearantly, the Davinci
platform probes this driver with the clock all powered up, but on OMAP,
this isn't the case.
Signed-off-by: Daniel Mack
---
drivers/net/ethernet/ti/davinci_mdio.c | 16 ++--
1 file changed, 14 insertions(+), 2 deleti
On 07/04/2012 01:56 AM, Sascha Hauer wrote:
> This patch adds a helper function for parsing videomodes from the devicetree.
> The videomode can be either converted to a struct drm_display_mode or a
> struct fb_videomode.
> diff --git a/Documentation/devicetree/bindings/video/displaymode
> b/Docum
On Thu, Aug 02, 2012 at 10:21:57AM +0200, Thierry Reding wrote:
> On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
> > The problem is, how do we turn these phandles into the resource of
> > interest. The type of the resource can be infered by the name of the
> > property. The hard par
On Thu, Aug 02, 2012 at 11:11:21AM -0600, Stephen Warren wrote:
> Samuel, please don't apply this just yet though - it looks like I need
> to make some minor changes to the header file and DT binding
> documentation to add in a definition for one more regulator. I'll repost
> the amended version a
On 08/02/2012 10:15 AM, Mark Brown wrote:
> On Wed, Aug 01, 2012 at 02:48:05PM -0600, Stephen Warren wrote:
>> From: Gyungoh Yoo
>>
>> The MAX8907 is an I2C-based power-management IC containing voltage
>> regulators, a reset controller, a real-time clock, and a touch-screen
>> controller.
>
> Rev
Dear All,
We are working on device tree backporting from 3.0 kernel to
2.6.32-kernel.
We have backported the device tree support for arm on 2.6.32. It is able to
read machine name,
memory size and command line parameter from devicetree file for arm based
target board.
But it failed to read driv
On 08/02/2012 05:16 AM, Laxman Dewangan wrote:
> Device have SYS rail which is always ON. It is system
> power bus. LDO5 and LDO_RTC get powered through this rail
> internally. Add support for this rail and make the
> LDO5/LDO_RTC input supply to "sys".
> Update document accordingly.
I believe you
On Wed, Aug 1, 2012 at 12:03 PM, Sylwester Nawrocki
wrote:
> It wouldn't be clear what specific SoCs the "samsung,exynos5-gsc" compatible
> string applies to, would it ? I believe there are already minor differences
> in GScaler parameters on currently available exynos5 SoC. The variant data
> st
On Wed, Aug 01, 2012 at 02:48:05PM -0600, Stephen Warren wrote:
> From: Gyungoh Yoo
>
> The MAX8907 is an I2C-based power-management IC containing voltage
> regulators, a reset controller, a real-time clock, and a touch-screen
> controller.
Reviewed-by: Mark Brown
__
On Thu, Aug 02, 2012 at 05:21:38PM +0530, Laxman Dewangan wrote:
> On Thursday 02 August 2012 05:10 PM, Mark Brown wrote:
> >Is the system rail actually regulated or is it just a nominal 5V?
> >Normally it's just the raw, unregulated input switched in with FETs or
> >whatever.
> It is unregulated
Add device tree support to C_CAN/D_CAN controller and usage details
are added to device tree documentation. Driver was tested on AM335x
EVM.
Signed-off-by: AnilKumar Ch
---
.../devicetree/bindings/net/can/c_can.txt | 37 +
drivers/net/can/c_can/c_can_platform.c
Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
APIs control clocks for C_CAN/D_CAN IP and prevent access to the
register of C_CAN/D_CAN IP when clock is turned off.
Signed-off-by: AnilKumar Ch
---
drivers/net/can/c_can/c_can_platform.c |8
1 file changed, 8 inserti
This patch series adds the device tree support and Runtime PM support
to C_CAN/D_CAN controller. First patch cleans up the device names used
in c_can driver.
These patches have been tested on AM335x EVM using some additional
patches to add device tree data to EVM dts files and to initialize
D_CAN
Modify c_can device names from *_CAN_DEVTYPE to BOSCH_*_CAN to make
use of same names for array indexes in c_can_id_table[] as well as
device names.
This patch also add indexes to c_can_id_table array.
Signed-off-by: AnilKumar Ch
---
drivers/net/can/c_can/c_can.h |5 +++--
drivers/
Hi Arnd,
Thanks for the review
On Thu, Aug 02, 2012 at 17:03:59, Arnd Bergmann wrote:
> On Thursday 02 August 2012 16:32:17 AnilKumar Ch wrote:
> > +- interrupt-parent : The parent interrupt controller
> > +
> > +Optional properties:
> > +- ti,hwmods: Must be "d_can" or "c_can", n
On 08/02/2012 01:39 PM, AnilKumar, Chimata wrote:
[...]
> AnilKumar Ch (3):
> can: c_can: Add device tree support to Bosch C_CAN/D_CAN controller
> can: c_can: Modify c_can device names in c_can_pci driver
You break bisectability here. After patch 1 the pci driver will not
On Thu, Aug 02, 2012 at 04:46:33PM +0530, Laxman Dewangan wrote:
> +static const unsigned int tps6586x_sys_voltages[] = {
> + 500,
> +};
Is the system rail actually regulated or is it just a nominal 5V?
Normally it's just the raw, unregulated input switched in with FETs or
whatever.
_
Marc,
On Thu, Aug 02, 2012 at 16:53:38, Marc Kleine-Budde wrote:
> On 08/02/2012 01:21 PM, AnilKumar, Chimata wrote:
> > Marc,
> >
> > On Thu, Aug 02, 2012 at 16:43:04, Marc Kleine-Budde wrote:
> >> On 08/02/2012 01:02 PM, AnilKumar Ch wrote:
> >>> This patch series adds the device tree support a
On Thursday 02 August 2012 16:32:17 AnilKumar Ch wrote:
> +- interrupt-parent : The parent interrupt controller
> +
> +Optional properties:
> +- ti,hwmods: Must be "d_can" or "c_can", n being the
> + instance number
interrupt-parent should be optional, not m
On Thursday 02 August 2012, Praveen Paneri wrote:
> Yes! I understand this problem and this is the reason these patches
> were sitting in my system for couple of weeks. In a discussion with
> Thomas an idea of using the existing regulator framework to
> enable/disable numerous PHYs came up. For ex
On 08/02/2012 01:21 PM, AnilKumar, Chimata wrote:
> Marc,
>
> On Thu, Aug 02, 2012 at 16:43:04, Marc Kleine-Budde wrote:
>> On 08/02/2012 01:02 PM, AnilKumar Ch wrote:
>>> This patch series adds the device tree support and Runtime PM support
>>> to C_CAN/D_CAN controller.
>>>
>>> These patches hav
Marc,
On Thu, Aug 02, 2012 at 16:43:04, Marc Kleine-Budde wrote:
> On 08/02/2012 01:02 PM, AnilKumar Ch wrote:
> > This patch series adds the device tree support and Runtime PM support
> > to C_CAN/D_CAN controller.
> >
> > These patches have been tested on AM335x EVM using some additional
> > pa
On 08/02/2012 01:02 PM, AnilKumar Ch wrote:
> This patch series adds the device tree support and Runtime PM support
> to C_CAN/D_CAN controller.
>
> These patches have been tested on AM335x EVM using some additional
> patches to add device tree data to EVM dts files and to initialize
> D_CAN RAM.
Add Runtime PM support to C_CAN/D_CAN controller. The runtime PM
APIs control clocks for C_CAN/D_CAN IP and prevent access to the
register of C_CAN/D_CAN IP when clock is turned off.
Signed-off-by: AnilKumar Ch
---
drivers/net/can/c_can/c_can_platform.c |8
1 file changed, 8 inserti
Modify c_can device names from *_CAN_DEVTYPE to BOSCH_*_CAN to make
use of same names in platform_device_id struct and of_device_id
struct.
Signed-off-by: AnilKumar Ch
---
drivers/net/can/c_can/c_can_pci.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/c
Add device tree support to C_CAN/D_CAN controller and usage details
are added to device tree documentation. Driver was tested on AM335x
EVM.
Signed-off-by: AnilKumar Ch
---
.../devicetree/bindings/net/can/c_can.txt | 37 +
drivers/net/can/c_can/c_can.h
This patch series adds the device tree support and Runtime PM support
to C_CAN/D_CAN controller.
These patches have been tested on AM335x EVM using some additional
patches to add device tree data to EVM dts files and to initialize
D_CAN RAM. D_CAN raminit is controlled from control module register
Hi Marc,
On Thu, Aug 02, 2012 at 13:29:44, Marc Kleine-Budde wrote:
> On 07/25/2012 04:12 PM, AnilKumar, Chimata wrote:
> > Marc,
> >
> > On Wed, Jul 25, 2012 at 19:17:52, Marc Kleine-Budde wrote:
> >> On 07/25/2012 02:18 PM, AnilKumar Ch wrote:
> >>> Add device tree support to C_CAN/D_CAN contro
On Thu, Aug 02, 2012 at 05:27:44PM +0900, Alex Courbot wrote:
> On Thu 02 Aug 2012 05:21:57 PM JST, Thierry Reding wrote:
> >* PGP Signed by an unknown key
> >
> >On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
> >>On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >>>Oh I see. That's a
On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
> On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >Oh I see. That's a little confusing. Why not just reference the relevant
> >resources directly in each step; something more like:
> >
> > gpio@1 {
> > act
On 07/25/2012 04:12 PM, AnilKumar, Chimata wrote:
> Marc,
>
> On Wed, Jul 25, 2012 at 19:17:52, Marc Kleine-Budde wrote:
>> On 07/25/2012 02:18 PM, AnilKumar Ch wrote:
>>> Add device tree support to C_CAN/D_CAN controller and usage details
>>> are added to device tree documentation. Driver was tes
50 matches
Mail list logo
