On Thu, 22 Jan 2015 15:49:59 -0600
, Suman Anna
wrote:
> Hi Grant,
>
> On 01/13/2015 05:04 PM, Suman Anna wrote:
> > On 01/13/2015 04:00 PM, Rob Herring wrote:
> >> On Tue, Jan 13, 2015 at 3:25 PM, Suman Anna wrote:
> >>> Hi Rob,
> >>>
> >>> On 01/13/2015 02:38 PM, Rob Herring wrote:
> On
On Fri, Oct 10, 2014 at 1:29 PM, PERIER Romain wrote:
>>
>> What I'm more concerned about is the semantics of the property. What
>> do the generic code paths gain by standardizing this property? Is it
>> expected that
>
> We really need to come up with a standard property for this and document
> i
On Tue, Oct 7, 2014 at 8:43 PM, PERIER Romain wrote:
> This is not the final location, I have no idea exactly where I might
> put this helper function. This is why I ask you your opinion (and
> also, this is why that's a proposal)
>
> 2014-10-07 21:45 GMT+02:00 Romain Perier :
>> Several drivers c
On Mon, Jul 28, 2014 at 11:47 AM, Grygorii Strashko
wrote:
> Hi Grant.
>
> On 07/28/2014 05:05 PM, Grant Likely wrote:
>> On Thu, 12 Jun 2014 19:53:43 +0300, Grygorii Strashko
>> wrote:
>>> Use "clkops-clocks" property to specify clocks handled by
>
On Thu, 12 Jun 2014 19:53:43 +0300, Grygorii Strashko
wrote:
> Use "clkops-clocks" property to specify clocks handled by
> clock_ops domain PM domain. Only clocks defined in "clkops-clocks"
> set of clocks will be handled by Runtime PM through clock_ops
> Pm domain.
>
> Signed-off-by: Grygorii S
On Tue, 17 Jun 2014 10:09:31 +0100, Russell King - ARM Linux
wrote:
> On Mon, Jun 16, 2014 at 09:22:50AM -0400, Jason Kridner wrote:
> > Adding devicetree and linux-arm-kernel lists based on feedback on IRC...
> >
> > On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner wrote:
> > > I'd like to disc
On Tue, 29 Apr 2014 01:21:41 +0100, Russell King - ARM Linux
wrote:
> On Tue, Apr 29, 2014 at 09:02:27AM +0900, Simon Horman wrote:
> > On Mon, Apr 28, 2014 at 08:30:32PM +0100, Russell King wrote:
> > > Since we now automatically enable early BRESP in core L2C-310 code when
> > > we detect a Cor
On Thu, May 1, 2014 at 2:41 PM, Geert Uytterhoeven wrote:
> Hi Grant,
>
> On Thu, May 1, 2014 at 10:03 AM, Grant Likely
> wrote:
>> On Wed, 30 Apr 2014 23:54:37 +0200, Geert Uytterhoeven
>> wrote:
>>> On Tue, Apr 29, 2014 at 3:16 PM, Grant Likely
>>&
On Wed, 30 Apr 2014 23:54:37 +0200, Geert Uytterhoeven
wrote:
> Hi Grant,
>
> On Tue, Apr 29, 2014 at 3:16 PM, Grant Likely
> wrote:
> > On Fri, 25 Apr 2014 16:44:58 -0700, Kevin Hilman wrote:
> >> Geert Uytterhoeven writes:
> >>
> >> > When
On Fri, 25 Apr 2014 16:44:58 -0700, Kevin Hilman wrote:
> Geert Uytterhoeven writes:
>
> > When adding a device from DT, check if its clocks are suitable for Runtime
> > PM, and register them with the PM core.
> > If Runtime PM is disabled, just enable the clock.
> >
> > This allows the PM core
t
>>>> work correctly even before of_init is called.
>>>>
>>>> Afterwards introduce of_node_is_initialized & of_node_is_attached that
>>>> query the underlying kobject about the state (attached means kobj
>>>> is visible in sysfs)
On Sun, 27 Oct 2013 12:47:53 +0100, Pavel Machek wrote:
> > > > +#if IS_ENABLED(CONFIG_OF)
> > > I'm probably missing something here, but why not #ifdef CONFIG_OF?
> >
> > I have been told for other drivers, that IS_ENABLED() is
> > the prefered way to check for configuration these days.
>
> CON
On Tue, 22 Oct 2013 06:49:48 -0700, Tony Lindgren wrote:
> With the recent pinctrl-single changes, omaps can treat
> wake-up events from deeper idle states as interrupts.
>
> There's a separate "io chain" controller on most omaps
> that stays enabled when the device hits off-idle and the
> regula
or charging the backup battery.
> > +- bb-uamp: microamps for charging the backup battery.
>
> prop should have vendor prefix.
>
> ti,bb-uvolt, ti,bb-uamp
Agreed. Otherwise:
Acked-by: Grant Likely
>
> - k
>
> > +
> > +Examples:
> > +
> > +bc
On Thu, 19 Sep 2013 22:47:01 +0100, Russell King
wrote:
> AMBA Primecell devices always treat streaming and coherent DMA exactly
> the same, so there's no point in having the masks separated.
>
> Signed-off-by: Russell King
for the drivers/of/platform.c portion:
Acked-by:
On Thu, 12 Sep 2013 17:57:00 +0200, Alexander Holler
wrote:
> Am 12.09.2013 17:19, schrieb Stephen Warren:
> >
> > IRQs, DMA channels, and GPIOs are all different things. Their bindings
> > are defined independently. While it's good to define new types of
> > bindings consistently with other bind
gister child nodes in the core instead of doing this manually
> in each driver. So, fix the drivers and documentation, too.
>
> Acked-by: Rob Herring
> Reviewed-by: Felipe Balbi
> Acked-by: Rafael J. Wysocki
> Tested-by: Sylwester Nawrocki
> Signed-off-by: Wolf
On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij wrote:
> To solve this dilemma, perform an interrupt consistency check
> when adding a GPIO chip: if the chip is both gpio-controller and
> interrupt-controller, walk all children of the device tree,
> check if these in turn reference the interrupt-co
On Mon, 22 Jul 2013 16:16:07 -0500, Rob Herring wrote:
> On 07/21/2013 06:44 PM, Grant Likely wrote:
> > On Sun, Jul 21, 2013 at 9:48 PM, Rob Herring wrote:
> >> On 07/21/2013 09:42 AM, Rob Herring wrote:
> >>> On 07/19/2013 01:14 PM, Sebastian Andrzej Sie
On Sun, Jul 21, 2013 at 9:48 PM, Rob Herring wrote:
> On 07/21/2013 09:42 AM, Rob Herring wrote:
>> On 07/19/2013 01:14 PM, Sebastian Andrzej Siewior wrote:
>>> So I called of_platform_populate() on a device to get each child device
>>> probed and on rmmod and I need to reverse its doing. After a
On Mon, Jul 1, 2013 at 9:04 AM, Linus Walleij wrote:
> On Sun, Jun 30, 2013 at 2:25 AM, Javier Martinez Canillas
> wrote:
>
>> Yes, It doesn't apply cleanly to your "next" branch cleanly because
>> this patch-set depends on the following bugfix patch merged late on
>> the -rc cycle (3.10-rc7):
>>
or each GPIO used as an IRQ, the GPIO can be setup
> and configured as input there automatically.
>
> Signed-off-by: Javier Martinez Canillas
Acked-by: Grant Likely
> ---
>
> Changes since v2:
> - Only make the call to gpio_request_one() conditional in the DT
>
uring
> a GPIO as input and enabling the GPIO bank.
>
> Signed-off-by: Javier Martinez Canillas
Acked-by: Grant Likely
> ---
>
> Changes since v2:
> - Unconditionally do the IRQ setup in the .map() function and
> only call irq_create_mapping() in the gpio chip init to
Hi Linus,
It took a while to work out the correct solution to this regression.
It is sorted now. This branch was constructed and tested by Tony. I've
verified that it builds and signed the tag. Please pull into v3.10.
g.
The following changes since commit 9e895ace5d82df8929b16f58e9f515f6d54ab82d
On Tue, Jun 25, 2013 at 8:04 AM, Tony Lindgren wrote:
> * Grant Likely [130624 09:00]:
>> On Mon, Jun 24, 2013 at 8:21 AM, Tony Lindgren wrote:
>> > * Javier Martinez Canillas [130623 18:08]:
>> >> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen
>> >>
On Mon, Jun 24, 2013 at 8:21 AM, Tony Lindgren wrote:
> * Javier Martinez Canillas [130623 18:08]:
>> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen wrote:
>> > Hi,
>> >
>> > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote:
>> >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Ko
On Sat, 22 Jun 2013 00:50:54 +0200, Javier Martinez Canillas
wrote:
> When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
> has to be made to initialize the OMAP GPIO bank before a driver
> request the IRQ. Otherwise the call to request_irq() fails.
>
> Drives should not be aware
On Sat, 22 Jun 2013 00:50:53 +0200, Javier Martinez Canillas
wrote:
> When a GPIO is defined as an interrupt line using Device
> Tree, a call to irq_create_of_mapping() is made that calls
> irq_create_mapping(). So, is not necessary to do the mapping
> on the OMAP GPIO platform_driver and in fact
On Mon, 3 Jun 2013 23:39:16 -0700, Mike Turquette
wrote:
> Parses OMAP clock data from DT and registers those clocks with the clock
> framework. dt_omap_clk_init must be called early during boot for timer
> initialization so it is exported and called from the existing clock code
> instead of pr
On Tue, 11 Jun 2013 17:29:43 +0200, Javier Martinez Canillas
wrote:
> On 06/11/2013 04:48 PM, Florian Vaussard wrote:
> > Use the MTD constants for NAND and OneNAND nodes used in OMAP3
> > DTS.
> >
> > Signed-off-by: Florian Vaussard
> > ---
> > arch/arm/boot/dts/omap3-devkit8000.dts | 10 ++
0x0800
> +#define SZ_256M 0x1000
> +#define SZ_512M 0x2000
> +
> +#define SZ_1G 0x4000
> +#define SZ_2G0x8000
> +
> +#
On Tue, 11 Jun 2013 16:50:50 +0200, Florian Vaussard
wrote:
> Pinctrl headers were not protected with #ifndef.
>
> Signed-off-by: Florian Vaussard
Obviously this needs to go in via whatever tree added the modified
header files.
Acked-by: Grant Likely
> ---
> include/dt-b
rd-off-ns = <34>;
> >> +gpmc,adv-wr-off-ns = <44>;
> >> +gpmc,we-off-ns = <40>;
> >> +gpmc,oe-off-ns = <54>;
> >> +gpmc,access-ns = <64>;
> >> +gpmc,rd-cycle-ns = <82>;
> >> +gpmc,wr-cycle-ns = <82&g
On Fri, 26 Apr 2013 16:31:24 -0500, Jon Hunter wrote:
>
> On 04/26/2013 02:31 AM, Linus Walleij wrote:
> > On Wed, Apr 17, 2013 at 2:41 AM, Javier Martinez Canillas
> > wrote:
> >
> > So:
> >
> >> +static int omap_gpio_irq_domain_xlate(struct irq_domain *d,
> >> +
On Fri, 5 Apr 2013 09:48:08 +0200, Javier Martinez Canillas
wrote:
[...]
> irq_of_parse_and_map() calls to irq_create_of_mapping() which calls to
> the correct xlate function handler according to "#interrupt-cells"
> (irq_domain_xlate_onecell or irq_domain_xlate_twocell) and to
> irq_set_irq_typ
On Tue, 09 Apr 2013 00:44:05 +0200, Javier Martinez Canillas
wrote:
> On 04/09/2013 12:05 AM, Rob Herring wrote:
> > On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
> >> This means that drivers that need the IRQ type/level flags defined in
> >> the DT won't be able to get it.
> >
> > But
mp;irq_domain_simple_ops, NULL);
> + * if (!bank->domain)
> + * return -ENODEV;
> + */
> + irq_base = irq_alloc_descs(-1, 0, bank->width, 0);
> + if (irq_base < 0) {
> + dev_err(dev, "Couldn't allocate IRQ numbers\n");
> return -ENODEV;
> + }
> +
> + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base,
> + 0, &irq_domain_simple_ops, NULL);
>
> if (bank->regs->set_dataout && bank->regs->clr_dataout)
> bank->set_dataout = _set_gpio_dataout_reg;
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 16 Apr 2013 15:48:07 +0530, Kishon Vijay Abraham I
wrote:
> On Tuesday 16 April 2013 01:20 AM, Grant Likely wrote:
> > On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I
> > wrote:
> >> On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
> >&
MC NAND example.
>
> Signed-off-by: Jon Hunter
Acked-by: Grant Likely
> ---
> .../devicetree/bindings/mtd/gpmc-nand.txt | 28
> ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/
On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I
wrote:
> Hi,
>
> On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
> > On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I
> > wrote:
> >> The PHY framework provides a set of APIs for the PHY
On Tue, 19 Mar 2013 11:35:48 -0500, Jon Hunter wrote:
> Adds a function to read the various GPMC chip-select settings from
> device-tree and store them in the gpmc_settings structure.
>
> Update the GPMC device-tree binding documentation to describe these
> options.
>
> Signed-off-by: Jon Hunter
On Mon, 15 Apr 2013 16:06:37 +0530, Kishon Vijay Abraham I
wrote:
> Hi,
>
> On Monday 15 April 2013 03:50 PM, Grant Likely wrote:
> > On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I
> > wrote:
> >> Added a generic PHY framework that provides a set of
On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I
wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> PHY with or without using phandle. To obtain a reference to the PHY without
> using
On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I
wrote:
> Added a generic PHY framework that provides a set of APIs for the PHY drivers
> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
> the PHY with or without using phandle. To obtain a reference to the PHY
On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou
wrote:
> Hi Lee,
>
> On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
>
> > At the end of the line, some kind of hardware glue is going to be
> > needed.
> >
> > I just feel that drawing from a sample size of 1 (maybe 2 if I ge
...
> + baseboard_beaglebone: board@0 {
> + board-name = "A335FOO";
> + compatible-name = "ti,foo";
> + };
> +
> + slot@6 {
> + ti,cape-override;
> + compatible = "ti,foo";
> + board-name = "FOO-hardcoded";
> + version = "00A0";
> + manufacturer = "Texas Instruments";
> + part-number = "BB-BONE-FOO-01";
> + };
> + };
> +
> +};
> +
> --
> 1.7.12
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 19 Mar 2013 13:51:01 +0200, Pantelis Antoniou
wrote:
> Hi Grant,
>
> On Mar 16, 2013, at 11:24 AM, Grant Likely wrote:
>
> > On Wed, 23 Jan 2013 12:58:02 +0200, Pantelis Antoniou
> > wrote:
> >> Hi David,
> >>
> >> On Jan
On Tue, 19 Mar 2013 13:42:32 +0200, Pantelis Antoniou
wrote:
> Hi Grant,
>
> The 3rd patch is in preparation for some patches I have in WIP that would
> allow
> drivers to set notifications for properties that are changed in runtime.
Okay, submit it with that series then please.
g.
--
To uns
On Fri, 4 Jan 2013 21:31:07 +0200, Pantelis Antoniou
wrote:
> There are other users for the proc DT functions.
> Export them.
>
> Signed-off-by: Pantelis Antoniou
Hi Pantelis.
Patches 1 & 2 look good. No comments there.
This patch bothers me. The manipulation of the proc entries is part and
On Fri, 4 Jan 2013 21:31:07 +0200, Pantelis Antoniou
wrote:
> There are other users for the proc DT functions.
> Export them.
>
> Signed-off-by: Pantelis Antoniou
Actually, I cannot find the user of this patch. Why is it needed?
g.
--
To unsubscribe from this list: send the line "unsubscribe
On Wed, 23 Jan 2013 12:58:02 +0200, Pantelis Antoniou
wrote:
> Hi David,
>
> On Jan 23, 2013, at 6:40 AM, David Gibson wrote:
> > Ok. Nonetheless it's not hard to avoid a recursive approach here.
>
> How can I find the maximum phandle value of a subtree without using recursion.
> Note that the
On Fri, 1 Mar 2013 11:22:48 -0600, Jon Hunter wrote:
> For OMAP devices, if a gpio is being used as an interrupt source but has
> not been requested by calling gpio_request(), a call to request_irq()
> may cause the kernel hang because the gpio bank may be disabled and
> hence the register access
On Fri, 1 Mar 2013 11:22:47 -0600, Jon Hunter wrote:
> Currently the OMAP GPIO driver uses a legacy mapping for the GPIO IRQ
> domain. This is not necessary because we do not need to assign a
> specific interrupt number to the GPIO IRQ domain. Therefore, convert
> the OMAP GPIO driver to use a lin
On Tue, 26 Feb 2013 17:01:22 -0600, Jon Hunter wrote:
>
> On 02/26/2013 04:44 PM, Stephen Warren wrote:
> > On 02/26/2013 03:40 PM, Jon Hunter wrote:
> >> On 02/26/2013 04:01 AM, Javier Martinez Canillas wrote:
> >> Are you requesting the gpio anywhere? If not then this is not going to
> >> work
On Sun, Feb 10, 2013 at 11:35 AM, Javier Martinez Canillas
wrote:
> On Sun, Feb 10, 2013 at 10:37 AM, Russell King - ARM Linux
> wrote:
>> On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
>>> I knew this would be controversial and that's why I didn't mean it to be a
>>>
de already set correctly?
>
> Manually creating platform devices and adding DT nodes to it sounds like
> the wrong thing to be doing.
Right; I'd expect your platform device creation to go through the
of_platform_populate() route. What is your use-case?
g.
--
Grant Likely, B
On Wed, 6 Feb 2013 16:17:24 +0530, Santosh Shilimkar
wrote:
> On Wednesday 06 February 2013 04:14 PM, Chen Gang wrote:
> >
> >'const static ' is not a common order, better to use 'static const'
> > instead.
> >
> > building:
> >make EXTRA_CFLAGS=-W ARCH=arm
> >
> >drivers/gpio/gpio-o
On Thu, 10 Jan 2013 14:09:35 +0100, Peter Ujfalusi
wrote:
> Hi Linus,
>
> On 01/10/2013 11:41 AM, Linus Walleij wrote:
> > On Thu, Dec 20, 2012 at 10:44 AM, Peter Ujfalusi
> > wrote:
> >
> >> Use more coherent locking in the driver. Use bitfield to store the GPIO
> >> direction and if the pin
0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
> + >;
> + };
> +
> + mmc1: mmc@4806 {
> + pinctrl-names = "default", "idle";
> + pinctrl-0 = <&mmc1_pins>;
> + pinctrl-1 = <&
On Thu, Dec 20, 2012 at 9:23 AM, Peter Ujfalusi wrote:
> On 12/19/2012 06:07 PM, Grant Likely wrote:
>> On Thu, 6 Dec 2012 11:52:07 +0100, Peter Ujfalusi
>> wrote:
>>> This GPIO driver should not configure anything else then GPIOs.
>>>
>>> Signed-off
On Fri, 14 Dec 2012 18:05:53 +1100, NeilBrown wrote:
> On Mon, 10 Sep 2012 10:57:07 -0700 Kevin Hilman
> wrote:
>
>
> > OK thanks, I'll queue this up for v3.6-rc as this should qualify as a
> > regression.
>
> I don't think this did actually get queued. At least I'm still seeing the
> bug in
On Wed, 19 Dec 2012 21:53:23 +0100, Michael Trimarchi
wrote:
> Hi
>
> Grant Likely wrote:
>
> >On Thu, 6 Dec 2012 11:52:06 +0100, Peter Ujfalusi
> > wrote:
> >> Use more coherent locking in the driver. Use bitfield to store the
> >GPIO
> >>
if (status)
> dev_dbg(&pdev->dev, "setup --> %d\n", status);
> }
> @@ -510,18 +527,19 @@ out:
> static int gpio_twl4030_remove(struct platform_device *pdev)
> {
> struct twl4030_gpio_platform_data *pdata = pdev->dev.platform_da
ched_leden;
>
> /* The LED lines are open drain outputs ... a FET pulls to GND, so an
> --
> 1.8.0
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
v->out_state &= ~BIT(offset);
> +
> + mutex_unlock(&priv->mutex);
> }
>
> -static void twl_set(struct gpio_chip *chip, unsigned offset, int value)
> +static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int
> value)
> {
> + stru
On Sat, 15 Dec 2012 16:55:46 +0200, Felipe Balbi wrote:
> On Sat, Dec 15, 2012 at 12:32:24AM +0000, Grant Likely wrote:
> > On Wed, 12 Dec 2012 10:46:00 +0200, Felipe Balbi wrote:
> > > there are a few spi master drivers which make
> > > use of that flag but
parse the generic GPMC timing parameters and some
> documentation with examples on how to use them.
>
> Successfully tested on an AM33xx board.
>
> Signed-off-by: Daniel Mack
For all patches in this series:
Acked-by: Grant Likely
--
To unsubscribe from this list: send the lin
|= SPI_CS_HIGH;
> if (of_find_property(nc, "spi-3wire", NULL))
> spi->mode |= SPI_3WIRE;
> + if (of_find_property(nc, "spi-loopback", NULL))
> + spi->mode |= SPI_LOOP;
>
>
On Wed, 12 Dec 2012 17:02:10 -0600, Jon Hunter wrote:
>
> So looking at this today, here is what I see when comparing the
> registers ...
>
> omap2430 != omap2420
> omap3430 != omap2430
> omap3630 == omap3430
> omap4430 != omap3430
> omap4460 == omap4430
> omap543x == omap4430
> am335x != omap44
;
>
> - complete(&mcspi_dma->dma_tx_completion);
> -
> /* We must disable the DMA TX request */
> omap2_mcspi_set_dma_req(spi, 0, 0);
> +
> + complete(&mcspi_dma->dma_tx_completion);
> }
>
> static void omap2_mcspi_tx_dma(struct spi
On Wed, Dec 12, 2012 at 11:12 AM, Peter Ujfalusi wrote:
> Hi Grant,
>
> On 12/07/2012 09:09 AM, Linus Walleij wrote:
>> On Thu, Dec 6, 2012 at 11:52 AM, Peter Ujfalusi
>> wrote:
>>
>>> As Grant commneted on the first version:
>>> https://lkml.org/lkml/2012/12/5/53
>>>
>>> Introduce bitfields to
On Thu, 29 Nov 2012 17:16:33 +0530, "Philip, Avinash"
wrote:
> The ELM hardware module can be used to speedup BCH 4/8/16 ECC scheme
> error correction.
> For now only 4 & 8 bit support is added
>
> Signed-off-by: Philip, Avinash
> Cc: Grant Likely
>
nt: phandle for the interrupt controller
>
> +Optional properties:
> +- ti,system-power-controller: Telling whether or not rtc is controlling
> + the system power.
> +
Acked-by: Grant Likely
> Example:
>
> rtc@1c23000 {
> @@ -14,4 +18,5 @@ rtc@1c23000 {
>
On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter wrote:
> Hi Grant,
>
> On 12/05/2012 04:22 PM, Grant Likely wrote:
> > On Wed, 5 Dec 2012 20:09:31 +0100, Daniel Mack wrote:
> >> This patch adds basic DT bindings for OMAP GPMC.
> >>
> >> The actual per
On Wed, 5 Dec 2012 10:49:45 +0100, Peter Ujfalusi wrote:
> When the GPIO is configured as output we need to read the GPIODATAOUT*
> register to get correct information. When the GPIO is output the GPIODATAIN*
> registers report 0 all the time (no feedback from output path).
>
> Signed-off-by: Pet
return 0;
> +}
> +#else
> +static int gpmc_probe_nand_child(struct platform_device *pdev,
> + struct device_node *child)
> +{
> + return 0;
> +}
> +#endif
> +
> +static int gpmc_probe_dt(struct platform_device *pdev)
> +{
> + int ret;
> + struct device_node *child;
> + const struct of_device_id *of_id =
> + of_match_device(gpmc_dt_ids, &pdev->dev);
> +
> + if (!of_id)
> + return 0;
> +
> + for_each_node_by_name(child, "nand") {
> + ret = gpmc_probe_nand_child(pdev, child);
> + of_node_put(child);
> + if (ret < 0)
> + return ret;
> + }
> +
> + return 0;
> +}
> +#else
> +static int gpmc_probe_dt(struct platform_device *pdev)
> +{
> + return 0;
> +}
> +#endif
> +
> +static int __devinit gpmc_probe(struct platform_device *pdev)
> {
> int rc;
> u32 l;
> @@ -1174,6 +1334,14 @@ static __devinit int gpmc_probe(struct platform_device
> *pdev)
> if (IS_ERR_VALUE(gpmc_setup_irq()))
> dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
>
> + rc = gpmc_probe_dt(pdev);
> + if (rc < 0) {
> + clk_disable_unprepare(gpmc_l3_clk);
> + clk_put(gpmc_l3_clk);
> + dev_err(gpmc_dev, "failed to probe DT parameters\n");
> + return rc;
> + }
> +
> return 0;
> }
>
> @@ -1191,6 +1359,7 @@ static struct platform_driver gpmc_driver = {
> .driver = {
> .name = DEVICE_NAME,
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(gpmc_dt_ids),
> },
> };
>
> --
> 1.7.11.7
>
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 30, 2012 at 11:04 AM, Thierry Reding
wrote:
>> > One other problem is that some PWM devices cannot be setup to achieve a
>> > 0% or 100% duty-cycle but instead will toggle for at least one period.
>> > This would be another argument in favour of moving the functionality to
>> > the in
On Fri, 30 Nov 2012 07:47:52 +0100, Thierry Reding
wrote:
> On Thu, Nov 29, 2012 at 04:10:24PM +0000, Grant Likely wrote:
> > On Wed, 28 Nov 2012 09:54:57 +0100, Peter Ujfalusi
> > wrote:
> > > Hi Grant, Lars, Thierry,
> > >
> > > On 11/26/2012 04
On Wed, 28 Nov 2012 09:54:57 +0100, Peter Ujfalusi
wrote:
> Hi Grant, Lars, Thierry,
>
> On 11/26/2012 04:46 PM, Grant Likely wrote:
> > You're effectively asking the pwm layer to behave like a gpio (which
> > is completely reasonable). Having a completely separate t
On Fri, 23 Nov 2012 10:44:36 +0100, Peter Ujfalusi
wrote:
> Hi Grant,
>
> On 11/23/2012 10:13 AM, Peter Ujfalusi wrote:
> > Hi Grant,
> >
> > On 11/23/2012 08:55 AM, Grant Likely wrote:
> >> Ugh. and this is why I wanted the PWM and GPIO subsystems to use
into a GPIO (with output only of course). The gpio properties should
appear directly in the PWM node itself and the translation code should
be in either the pwm or the gpio core. I don't think it should look like
a separate device.
g.
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Techno
On Sat, 17 Nov 2012 23:27:18 +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> On 16:23 Fri 09 Nov , Stephen Warren wrote:
> > On 11/09/2012 09:28 AM, Grant Likely wrote:
> > However, I think the process for an end-user needs to be as simple as
> > "drop this .dts/.d
On Wed, 31 Oct 2012 17:57:33 +0200, Pantelis Antoniou
wrote:
> Export an interface that other in-kernel users can utilize.
>
> Signed-off-by: Pantelis Antoniou
I'm not going to apply this before an in-kernel user exists for this. I
know it's part of the whole runtime population of the device t
On Wed, 31 Oct 2012 21:04:24 -0500, Rob Herring wrote:
> On 10/31/2012 10:57 AM, Pantelis Antoniou wrote:
> > This simple patch enables dynamic changes of the DT tree on runtime
> > to be visible to the device-tree proc interface.
> >
> > Signed-off-by: Pantelis Antoniou
>
> Acked-by: Rob Herri
On Tue, Nov 13, 2012 at 8:09 AM, Pantelis Antoniou
wrote:
> On Nov 13, 2012, at 9:25 AM, David Gibson wrote:
> Not good to rely on userspace kicking off dtc and compiling from source.
> Some capes/expansion boards might have your root fs device, for example
> there is an eMMC cape coming up, while
On Mon, Nov 12, 2012 at 11:34 AM, Pantelis Antoniou
wrote:
> Hi Grant,
>
> On Nov 9, 2012, at 10:33 PM, Grant Likely wrote:
>
>> On Wed, Nov 7, 2012 at 11:02 AM, Pantelis Antoniou
>> wrote:
>>> On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote:
>>>>
On Fri, Nov 9, 2012 at 11:23 PM, Stephen Warren wrote:
> On 11/09/2012 09:28 AM, Grant Likely wrote:
>> On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren
>> wrote:
> ...
>>> I do rather suspect this use-case is quite common. NVIDIA certainly has
>>> a bunch
On Fri, Nov 9, 2012 at 11:06 PM, Stephen Warren wrote:
> On 11/05/2012 01:40 PM, Grant Likely wrote:
>> As promised, here is my early draft to try and capture what device
>> tree overlays need to do and how to get there. Comments and
>> suggestions greatly appreciated.
On Fri, Nov 9, 2012 at 10:57 PM, Stephen Warren wrote:
> On 11/08/2012 07:26 PM, David Gibson wrote:
> ...
>> I also think graft will handle most of your use cases, although as I
>> said I don't fully understand the implications of some of them, so I
>> could be wrong. So, the actual insertion of
On Fri, Nov 9, 2012 at 2:26 AM, David Gibson
wrote:
> (3) Resolving phandle references from the subtree to the main tree.
>
> So, I think this can actually be avoided, at least in cases where what
> physical connections are available to the expansion module is well
> defined. The main causes to h
On Fri, Nov 9, 2012 at 5:32 AM, Joel A Fernandes wrote:
> Hi Pantelis,
>
> I hope I'm not too late to reply as I'm traveling.
>
> On Nov 6, 2012, at 5:30 AM, Pantelis Antoniou
> wrote:
>
>>
>>>
>>> Joanne has purchased one of Jane's capes and packaged it into a rugged
>>> case for data logging. A
On Fri, Nov 9, 2012 at 2:26 AM, David Gibson
wrote:
>> Summary points:
>> - Create an FDT overlay data format and usage model
>> - SHALL reliable resolve or validate of phandles between base and
>> overlay trees
>
> So, I'm not at all clear on what this proposed phandle validation
> would in
On Wed, Nov 7, 2012 at 11:02 AM, Pantelis Antoniou
wrote:
> On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote:
>> Maybe some extra version match table can just be passed during the board
>> machine_init
>>
>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL,
>> panda_version_matc
On Wed, Nov 7, 2012 at 8:06 AM, Pantelis Antoniou
wrote:
> Hi Grant,
>
> On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
>> Yes, the locking does need to be sorted out.
>>
>
> Perhaps come up with a dt-stress test tool/boot time validator?
I would like that. I've
On Wed, Nov 7, 2012 at 12:54 AM, Mitch Bradley wrote:
> On 11/6/2012 12:37 PM, Stephen Warren wrote:
>> This proposal is very oriented at an overlay-based approach. I'm not
>> totally convinced that a pure overlay approach (as in how dtc does
>> overlayed DT nodes) will be flexible enough, but wou
On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren wrote:
> On 11/05/2012 01:40 PM, Grant Likely wrote:
>> Hey folks,
>>
>> As promised, here is my early draft to try and capture what device
>> tree overlays need to do and how to get there. Comments and
>>
On Mon, Nov 5, 2012 at 11:22 PM, Tony Lindgren wrote:
> Hi,
>
> * Tabi Timur-B04825 [121105 13:42]:
>> On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely
>> wrote:
>>
>> > Jane is building custom BeagleBone expansion boards called 'capes'. She
>> &
On Tue, Nov 6, 2012 at 8:45 PM, Grant Likely wrote:
> The back of a napkin calculation indicates that on this platform
> /proc/devicetree costs 76kB and /sys/device-tree costs 60kb. I'm happy
> to see that using /sys instead of /proc appears to be slightly cheaper
> which m
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
wrote:
> On Nov 6, 2012, at 12:14 PM, Grant Likely wrote:
>> On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou
>> wrote:
>>> For hot-plugging, you need it. Whether kernel code can deal with
>>> large parts of
On Tue, Nov 6, 2012 at 8:14 AM, Pantelis Antoniou
wrote:
> On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote:
>> Sure, so if we add data type supplementary properties to the tree to
>> indicate the data type as "indirect phandle", then kernel could refer
>> to the index in the got-like table to f
1 - 100 of 425 matches
Mail list logo
