On Fri, Nov 30, 2012 at 09:48:05AM +, Grant Likely wrote:
> > If you attempt to stick a 'reg' in a block nested below a
> > 'device_type="pci"' the kernel throws lots of error messsages and
> > generates bad address mappings.
>
> Have you added the appropriate #address-cells and #size-cells t
On 11/15/2012 11:20 AM, Grant Likely wrote:
On Mon, 12 Nov 2012 16:28:22 -0500, Murali Karicheri
wrote:
This adds OF support to DaVinci SPI controller to configure platform
data through device bindings.
Signed-off-by: Murali Karicheri
Hi Murali,
Comments below...
---
.../devicetree/bin
Signed-off-by: Marek Belisko
---
Documentation/devicetree/bindings/leds/tca6507.txt | 33
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/tca6507.txt
diff --git a/Documentation/devicetree/bindings/leds/tca6507.txt
b/Documentatio
Support added only for leds (not for gpio's).
Signed-off-by: Marek Belisko
---
Changes from v3:
- fix code according Bryan suggestions
- use common leds binding description instead copy'n'paste
- use "-" instead "_" in bindings example for leds names
Changes from v2:
- change compatible property
On 30 November 2012 21:15, Lee Jones wrote:
> But ... I don't see how the changes in the -i2c and -spi files
> are of benefit either. When I boot without the ID table I still
> get "stmpe-i2c 0-0040: stmpe1601 detected, chip id: 0x212".
>
> What is it that actually uses the IDs?
>
> Perhaps Viresh
Hi Tony,
Hi Andreas,
On 30.11.2012 18:40, Tony Lindgren wrote:
> * Andreas Fenkart [121130 03:21]:
>>
>> The alternative was to configure dat1 line as a GPIO, while
>> waiting for an IRQ. Then configuring it back as dat1 when the
>> SDIO card is signalling an IRQ. Or the host starts a transfer. I
* Andreas Fenkart [121130 03:21]:
>
> The alternative was to configure dat1 line as a GPIO, while
> waiting for an IRQ. Then configuring it back as dat1 when the
> SDIO card is signalling an IRQ. Or the host starts a transfer. I
> guess this will perform poorly, hence not considering it really.
On 11/30/2012 02:04 AM, Grant Likely wrote:
> From: Randy Dunlap
>
> ERROR: "allnodes" [drivers/w1/masters/w1-gpio.ko] undefined!
>
> Signed-off-by: Randy Dunlap
> [grant.likely: allnodes is too generic; rename to of_allnodes]
> Signed-off-by: Grant Likely
> Cc: Ville Syrjala
That builds.
On Fri, 30 Nov 2012, Samuel Ortiz wrote:
> Hi Viresh, Lee,
>
> On Thu, Nov 29, 2012 at 08:10:18PM +0530, Viresh Kumar wrote:
> > From: Vipul Kumar Samar
> >
> > This patch extends existing DT support for stmpe devices. This updates:
> > - DT support from stmpe SPI and I2C drivers
> > - missing
On Fri, 30 Nov 2012, Philip, Avinash wrote:
> Is there any way to get HWMOD and DT patches getting accepted in 3.8?
> Or should I wait and send rebased patch based on 3.8-rc1?
Our upstreams aren't taking any more new features for v3.8, so basing on
v3.8-rc1 is the best thing to do now.
In the m
On 11/29/2012 05:47 PM, Vinod Koul wrote:
> On Thu, 2012-11-29 at 16:24 -0600, Jon Hunter wrote:
>> When compiling the kernel with DMA engine support enabled and device-tree
>> support disabled, the following warnings are observed.
> Thanks, already committed same change last night.
Great! Thanks
On Nov 30, 2012 6:50 PM, "Lee Jones" wrote:
>
> On Fri, 30 Nov 2012, Viresh Kumar wrote:
>
> > On 30 November 2012 18:15, Lee Jones wrote:
> > > The patch doesn't apply for me - does it for you?
> > >
> > > Viresh, what's it based on?
> >
> > Because this was applied 2 days back by Samuel, and i
On Fri, 30 Nov 2012, Viresh Kumar wrote:
> On 30 November 2012 18:15, Lee Jones wrote:
> > The patch doesn't apply for me - does it for you?
> >
> > Viresh, what's it based on?
>
> Because this was applied 2 days back by Samuel, and i didn't
> fetch it again yesterday:
>
> commit 20d5c7defc228c
On 30 November 2012 18:15, Lee Jones wrote:
> The patch doesn't apply for me - does it for you?
>
> Viresh, what's it based on?
Because this was applied 2 days back by Samuel, and i didn't
fetch it again yesterday:
commit 20d5c7defc228cdaeff3ce3442f3a4e86af293c1
Author: Randy Dunlap
Date: Mon
On Fri, 30 Nov 2012, Samuel Ortiz wrote:
> Hi Viresh, Lee,
>
> On Thu, Nov 29, 2012 at 08:10:18PM +0530, Viresh Kumar wrote:
> > From: Vipul Kumar Samar
> >
> > This patch extends existing DT support for stmpe devices. This updates:
> > - DT support from stmpe SPI and I2C drivers
> > - missing
On Thu, 2012-11-22 at 14:37 +, Philip, Avinash wrote:
> Idea here is to make faster scanning of erased page without bit flips.
> For omap nand driver ecc reported by hardware is non-zero and non
> 0xff.
> So comparing with the standard vector for erased page and skipping
> error
> correction fo
On Wed, 2012-10-31 at 12:38 +0530, Philip, Avinash wrote:
> +static int erased_sector_bitflips(u_char *data, u_char *oob,
> + struct omap_nand_info *info)
> +{
> + int flip_bits = 0, i;
> +
> + for (i = 0; i < info->nand.ecc.size; i++) {
> + flip_bits += hwei
On Wed, Nov 28, 2012 at 6:50 PM, Tomasz Figa wrote:
> Hi Praveen,
>
> On Friday 23 of November 2012 09:54:51 Praveen Paneri wrote:
>> We will anyway remove the platform data part soon. If you say I can
>> resend it again.
>
> I think that the requirement for platform data on DT-enabled systems
> s
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, Nov 30, 2012 at 10:20:38AM +, Grant Likely wrote:
> On Fri, 30 Nov 2012 07:47:52 +0100, Thierry Reding
> wrote:
> > On Thu, Nov 29, 2012 at 04:10:24PM +, Grant Likely wrote:
> > > On Wed, 28 Nov 2012 09:54:57 +0100, Peter Ujfalusi
> > > wrote:
> > > > Hi Grant, Lars, Thierry,
>
On 11/29/2012 05:10 PM, Grant Likely wrote:
>> /* Enable GPIO us of the PWMs */
>> gpio-controller = <1>;
>
> This line should be simply (the property shouldn't have any data):
> gpio-controller;
Yes I know. It is like this already in my code. I just mixed up things while
hacking
Hi Viresh, Lee,
On Thu, Nov 29, 2012 at 08:10:18PM +0530, Viresh Kumar wrote:
> From: Vipul Kumar Samar
>
> This patch extends existing DT support for stmpe devices. This updates:
> - DT support from stmpe SPI and I2C drivers
> - missing header files in stmpe.c
> - stmpe_of_probe() with pwm, rot
Hi Viresh,
On Thu, Nov 29, 2012 at 12:17:15AM +0530, Viresh Kumar wrote:
> Since the very first patch, stmpe core driver is using irq_invert_polarity as
> part of platform data. But, nobody is actually using it in kernel till now.
>
> Also, this is not something part of hardware specs, but is inc
On 11/30/2012 11:20 AM, Grant Likely wrote:
> Umm, I agree with you on duty cycle, but that's got nothing to do with
> period. 100% duty cycle looks exactly the same whether the period is
> 10ns or 100s.
Yes this is true. But some PWM hw can select it's clock based on the period_ns
provided.
In mo
On 11/29/2012 12:14 AM, Javier Martinez Canillas wrote:
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT
on OMAP3 SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL403
On 11/29/2012 12:14 AM, Javier Martinez Canillas wrote:
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas
---
Acked-by: Matthias Brugger
arch/arm/boot/dts/omap3-igep.dtsi | 93 ++
From: Randy Dunlap
Fix build when CONFIG_W1_MASTER_GPIO=m by exporting "allnodes".
ERROR: "allnodes" [drivers/w1/masters/w1-gpio.ko] undefined!
Signed-off-by: Randy Dunlap
Cc: Ville Syrjala
---
drivers/of/base.c |1 +
1 file changed, 1 insertion(+)
--- linux-next-20121129.orig/drivers/o
On Fri, 30 Nov 2012 07:47:52 +0100, Thierry Reding
wrote:
> On Thu, Nov 29, 2012 at 04:10:24PM +, Grant Likely wrote:
> > 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 effe
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas
Acked-by: Matthias Brugger
---
Changes since v1:
- Use default-state = "on" instead default-trigger
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT on OMAP3
SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio and pinctrl based mux).
Signed-off-by: Javier Mar
IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patch-set adds initial device
tree support for these devices.
The device tree allows to boot from an MMC/SD and are working all
the components that already have device tree support on OMAP3 SoCs:
Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.
Signed-off-by: Javier Martinez Canillas
Acked-by: Matthias Brugger
---
arch/arm/boot/dts/omap3-igep.dtsi | 93 +
1 files changed, 93 insertions(+), 0
From: Randy Dunlap
ERROR: "allnodes" [drivers/w1/masters/w1-gpio.ko] undefined!
Signed-off-by: Randy Dunlap
[grant.likely: allnodes is too generic; rename to of_allnodes]
Signed-off-by: Grant Likely
Cc: Ville Syrjala
---
arch/arm/mach-vexpress/v2m.c |2 +-
drivers/of/base.c|
On Thu, 29 Nov 2012 15:43:08 -0800, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix build when CONFIG_W1_MASTER_GPIO=m by exporting "allnodes".
>
> ERROR: "allnodes" [drivers/w1/masters/w1-gpio.ko] undefined!
>
> Signed-off-by: Randy Dunlap
> Cc: Ville Syrjala
> ---
> drivers/of/base.c |
On Thu, 29 Nov 2012 12:38:29 -0700, Jason Gunthorpe
wrote:
> On Thu, Nov 29, 2012 at 04:26:48PM +, Grant Likely wrote:
>
> > Hmmm. okay that makes sense, but something still isn't quite right. So
> > of_translate_address should take care of drilling down through the bus
> > layers, and when
On Wed, Nov 28, 2012 at 19:51:01, Thierry Reding wrote:
> On Tue, Nov 27, 2012 at 02:18:05PM +0530, Philip, Avinash wrote:
> > In AM33xx PWM sub modules like ECAP, EHRPWM & EQEP are integrated to
> > PWM subsystem. All these submodules shares the resources (clock) & has
> > a clock gating register
36 matches
Mail list logo
