* Stephen Warren wrote:
> On 03/14/2012 09:56 AM, Thierry Reding wrote:
> > From: Sascha Hauer
> >
> > This patch adds framework support for PWM (pulse width modulation) devices.
> ...
> > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> ...
> > +/**
> > + * pwmchip_add() - register a new p
* Stephen Warren wrote:
> On 03/14/2012 09:56 AM, Thierry Reding wrote:
> > This patch adds helpers to support device tree bindings for the generic
> > PWM API. Device tree binding documentation for PWM controllers is also
> > provided.
> ...
> > +static struct pwm_device *of_pwm_simple_xlate(struc
On 03/14/2012 09:56 AM, Thierry Reding wrote:
> This commit adds very basic support for device tree probing. Currently,
> only a PWM and a list of distinct brightness levels can be specified.
> Enabling or disabling backlight power via GPIOs is not yet supported.
>
> A pointer to the exit() callba
On 03/14/2012 09:56 AM, Thierry Reding wrote:
> Add auxdata to instantiate the PWFM controller from a device tree,
> include the corresponding nodes in the dtsi files for Tegra 20 and
> Tegra 30 and add binding documentation.
>
> Signed-off-by: Thierry Reding
> +++ b/Documentation/devicetree/bin
On 03/14/2012 09:56 AM, Thierry Reding wrote:
> This commit adds a generic PWM framework driver for the PWFM controller
> found on NVIDIA Tegra SoCs. The driver is based on code from the
> Chromium kernel tree and was originally written by Gary King (NVIDIA)
...
> diff --git a/drivers/pwm/pwm-tegra
On 03/14/2012 09:56 AM, Thierry Reding wrote:
> A subsequent patch will add a generic PWM API driver for the Tegra PWFM
> controller, supporting all four PWM devices with a single PWM chip. The
> device will be named tegra-pwm and only one clock needs to be provided.
>
> Signed-off-by: Thierry Red
On 03/14/2012 09:56 AM, Thierry Reding wrote:
> From: Simon Que
>
> PWM clock source registers in Tegra 2 have different clock source selection
> bit
> fields than other registers. PWM clock source bits in CLK_SOURCE_PWM_0
> register
> are located at bit field bit[30:28] while others are at bi
On 03/14/2012 09:56 AM, Thierry Reding wrote:
> This patch adds helpers to support device tree bindings for the generic
> PWM API. Device tree binding documentation for PWM controllers is also
> provided.
...
> +static struct pwm_device *of_pwm_simple_xlate(struct pwm_chip *pc,
> +
On 03/14/2012 09:56 AM, Thierry Reding wrote:
> From: Sascha Hauer
>
> This patch adds framework support for PWM (pulse width modulation) devices.
...
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
...
> +/**
> + * pwmchip_add() - register a new pwm
> + * @chip: the pwm
> + *
> + * regist
This TDM controller is available in various Freescale SOCs like MPC8315, P1020,
P1022, P1010.
Signed-off-by: Sandeep Singh
Signed-off-by: Poonam Aggrwal
---
Changes in v2:
- Incorporated Scott's Review comments
Documentation/devicetree/bindings/tdm/fsl-tdm.txt | 67 +++
On 03/08/2012 03:51 PM, Thierry Reding wrote:
From: Grant Likely
Allow drivers to report at probe time that they cannot get all the resources
required by the device, and should be retried at a later time.
This should completely solve the problem of getting devices
initialized in the right order
On Mon, 19 Mar 2012 17:49:02 +0100, Lothar WaÃmann
wrote:
> Hi,
>
> Grant Likely writes:
> > On Mon, 19 Mar 2012 07:54:33 +0100, Lothar WaÃmann
> > wrote:
> > > Grant Likely writes:
> > > > On Fri, 16 Mar 2012 11:01:35 +0800, Dong Aisheng
> > > > wrote:
> > > > > On Thu, Mar 15, 2012 at 07
On Thu, Mar 15, 2012 at 05:54:33PM +0100, Karol Lewandowski wrote:
> If you consider code to be inherently less readable because of this
> approach I'll rework it. If it's not a such big deal for you I would
> prefer to keep it as is.
The thing that was causing me to think the code was funny was
On Mon, Mar 19, 2012 at 9:41 PM, Arnd Bergmann wrote:
>
>> Secondly, there are platforms (Samsung) where peripherals are connected
>> to more than one DMA controller, and either DMA controller can be used -
>> I'm told by Jassi that there's reasons why you'd want to select one or
>> other as the t
On 03/19/2012 12:32 PM, Timur Tabi wrote:
> Scott Wood wrote:
Scott, are you suggesting that Poonam put a non-zero number in the DTS
for clock-frequency? If so, then I don't think that's a good idea, if
U-Boot will always override it.
>
>> This is a device tree binding document, no
Hi Nico,
On 3/19/2012 5:31 PM, Nicolas Ferre wrote:
On 03/19/2012 04:33 PM, Russell King - ARM Linux :
On Mon, Mar 19, 2012 at 02:06:34PM +, Arnd Bergmann wrote:
mmci
/* in drivers/dma/ste_dma40.c, others in pl330.c, coh901318.c, ... */
bool stedma40_filter(struct dma_chan *chan,
Scott Wood wrote:
>> > Scott, are you suggesting that Poonam put a non-zero number in the DTS
>> > for clock-frequency? If so, then I don't think that's a good idea, if
>> > U-Boot will always override it.
> This is a device tree binding document, not U-Boot specific. It
> describes what Linux (
On 03/17/2012 02:33 AM, Aggrwal Poonam-B10812 wrote:
>>> + - compatible
>>> + Usage: required
>>> + Value type:
>>> + Definition: Should contain "fsl,mpc8315-tdm".
>>> + So mpc8313 will have compatible = "fsl,mpc8315-tdm";
>>> + p1010 will have compatible "fsl,p1010-tdm", "
On 03/17/2012 11:07 AM, Tabi Timur-B04825 wrote:
> On Sat, Mar 17, 2012 at 2:33 AM, Aggrwal Poonam-B10812
> wrote:
>>
+ compatible = "fsl,p1010-tdm", "fsl,mpc8315-tdm";
+ reg = <0x16000 0x200 0x2c000 0x2000>;
+ clock-frequency = <0>;
>>>
>>> Show a real
On Fri, 2012-03-16 at 10:19 +0100, Stefan Roese wrote:
> This patch adds support to configure the FSMC NAND driver (used amongst
> others on SPEAr platforms) via device-tree instead of platform_data.
>
> Signed-off-by: Stefan Roese
Pushed to l2-mtd.git, thanks!
--
Best Regards,
Artem Bityutski
On 03/19/2012 09:45 AM, Arnd Bergmann wrote:
> On Monday 19 March 2012, Stephen Warren wrote:
>>> Maybe one can use named properties in a new device node in that case,
>>> like this:
>>>
>>> bus {
>>> dma: dma-controller {
>>> #dma-cells = <1>;
>>>
Hi,
Grant Likely writes:
> On Mon, 19 Mar 2012 07:54:33 +0100, Lothar Waßmann
> wrote:
> > Grant Likely writes:
> > > On Fri, 16 Mar 2012 11:01:35 +0800, Dong Aisheng
> > > wrote:
> > > > On Thu, Mar 15, 2012 at 07:22:04PM +0800, Lothar Waßmann wrote:
> > > > > Dong Aisheng writes:
> > > > > >
Hi Linus,
As the tag log message below states, nothing earth shattering here.
Just incremental updates. Please pull.
g.
The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:
Linux 3.3-rc1 (2012-01-19 15:04:48 -0800)
are available in the git repository at:
git://git
Hi Linus,
Here's the branch that generalizes powerpc's irq_host infrastructure
for all architectures. You can read the full description below (also
in the signed tag). I'm asking for this one to be pulled soon since
several of the arm branches are building on top of it. It's quite
important for
On 03/19/2012 04:33 PM, Russell King - ARM Linux :
> On Mon, Mar 19, 2012 at 02:06:34PM +, Arnd Bergmann wrote:
>> mmci
>> /* in drivers/dma/ste_dma40.c, others in pl330.c, coh901318.c, ... */
>> bool stedma40_filter(struct dma_chan *chan, void *data)
>> {
>> st
On Monday 19 March 2012, Russell King - ARM Linux wrote:
> Firstly, define what you mean by "the DMA parameters". Things like burst
> size, register width, register address? That should all be known by the
> peripheral driver and not be encoded into DT in any way - and this
> information should b
On 03/16/2012 03:54 PM, Stephen Warren wrote:
> This patch adds macros for_each_u32_property_value and
> for_each_string_property_value, which iterate over an array of values
> within a device-tree property. Usage is for example:
>
> struct of_iter_string_prop iter;
> for_each_string_property_valu
On 3/19/2012 4:20 PM, Russell King - ARM Linux wrote:
On Mon, Mar 19, 2012 at 02:37:56PM +0100, Nicolas Ferre wrote:
On 03/18/2012 09:13 PM, Arnd Bergmann :
On Saturday 17 March 2012, Grant Likely wrote:
+static LIST_HEAD(of_dma_list);
+
+struct of_dma {
+ struct list_head of_dma_controlle
On Monday 19 March 2012, Stephen Warren wrote:
> > Maybe one can use named properties in a new device node in that case,
> > like this:
> >
> > bus {
> > dma: dma-controller {
> > #dma-cells = <1>;
> > };
> >
> > device {
> >
On Mon, Mar 19, 2012 at 02:06:34PM +, Arnd Bergmann wrote:
> mmci
> /* in drivers/dma/ste_dma40.c, others in pl330.c, coh901318.c, ... */
> bool stedma40_filter(struct dma_chan *chan, void *data)
> {
> struct stedma40_chan_cfg *info = data;
> struct d40_
On Mon, Mar 19, 2012 at 02:37:56PM +0100, Nicolas Ferre wrote:
> On 03/18/2012 09:13 PM, Arnd Bergmann :
> > On Saturday 17 March 2012, Grant Likely wrote:
> >>> +static LIST_HEAD(of_dma_list);
> >>> +
> >>> +struct of_dma {
> >>> + struct list_head of_dma_controllers;
> >>> + struct device
On 03/19/2012 09:01 AM, Arnd Bergmann wrote:
> On Monday 19 March 2012, Mark Brown wrote:
>> On Sat, Mar 17, 2012 at 10:47:51AM +, Grant Likely wrote:
>>
>>> After implementing both schemes (ie. interrupts+interrupt-names &&
>>> [*-]gpios)
>>> I definitely prefer the fixed property name plus a
On Mon, 19 Mar 2012 07:54:33 +0100, Lothar WaÃmann
wrote:
> Grant Likely writes:
> > On Fri, 16 Mar 2012 11:01:35 +0800, Dong Aisheng
> > wrote:
> > > On Thu, Mar 15, 2012 at 07:22:04PM +0800, Lothar WaÃmann wrote:
> > > > Dong Aisheng writes:
> > > > > On Thu, Mar 15, 2012 at 02:53:29PM +080
On Monday 19 March 2012, Mark Brown wrote:
> On Sat, Mar 17, 2012 at 10:47:51AM +, Grant Likely wrote:
>
> > After implementing both schemes (ie. interrupts+interrupt-names &&
> > [*-]gpios)
> > I definitely prefer the fixed property name plus a separate names property.
> > It is easier to us
On Mon, 19 Mar 2012 14:30:05 +0100, Nicolas Ferre
wrote:
> On 03/17/2012 10:40 AM, Grant Likely :
> > On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre
> > wrote:
> >> +struct of_dma {
> >> + struct list_head of_dma_controllers;
> >> + struct device_node *of_node;
> >> + int of_dma_n_cells;
On Monday 19 March 2012, Nicolas Ferre wrote:
> > This _xlate is nearly useless as a generic API. It solves the problem for
> > the specific case where the driver is hard-coded to know which DMA engine
> > to talk to, but since the returned data doesn't provide any context, it
> > isn't useful if
Hi Ohad,
Ohad Ben-Cohen wrote:
Hi Michal,
On Tue, Mar 13, 2012 at 11:41 AM, Michal Simek wrote:
What do you think?
I'd really prefer to see some code to make sure I understand exactly
what you mean.
Any change you can post something ?
Maybe even just the hard coded forwarding implementati
On 03/18/2012 09:13 PM, Arnd Bergmann :
> On Saturday 17 March 2012, Grant Likely wrote:
>>> +static LIST_HEAD(of_dma_list);
>>> +
>>> +struct of_dma {
>>> + struct list_head of_dma_controllers;
>>> + struct device_node *of_node;
>>> + int of_dma_n_cells;
>>> + int (*of_dma_xlate)(s
On 03/17/2012 10:40 AM, Grant Likely :
> On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre
> wrote:
>> Add some basic helpers to retrieve a DMA controller device_node and the
>> DMA request specifications. By making DMA controllers register a generic
>> translation function, we allow the manageme
On Sat, Mar 17, 2012 at 10:47:51AM +, Grant Likely wrote:
> After implementing both schemes (ie. interrupts+interrupt-names && [*-]gpios)
> I definitely prefer the fixed property name plus a separate names property.
> It is easier to use common code with that scheme, and easier to statically
>
Hi Michal,
On Tue, Mar 13, 2012 at 11:41 AM, Michal Simek wrote:
> What do you think?
I'd really prefer to see some code to make sure I understand exactly
what you mean.
Any change you can post something ?
Maybe even just the hard coded forwarding implementation you have today.
Thanks,
Ohad.
41 matches
Mail list logo
