Re: [PATCH 09/15] mfd: kill off set_irq_flags usage

2015-06-11 Thread Lee Jones
On Tue, 09 Jun 2015, Rob Herring wrote:

 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:
 
 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN
 
 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also set IRQ_NOPROBE and this has been maintained although it is not
 clear that is really needed. There appears to be a great deal of blind
 copy and paste of this code.
 
 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Samuel Ortiz sa...@linux.intel.com
 Cc: Lee Jones lee.jo...@linaro.org
 Cc: Linus Walleij linus.wall...@linaro.org
 Cc: Milo Kim milo@ti.com
 Cc: Kumar Gala ga...@codeaurora.org
 Cc: Andy Gross agr...@codeaurora.org
 Cc: David Brown dav...@codeaurora.org
 Cc: Tony Lindgren t...@atomide.com
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: patc...@opensource.wolfsonmicro.com
 Cc: linux-arm-...@vger.kernel.org
 Cc: linux-...@vger.kernel.org
 Cc: linux-omap@vger.kernel.org
 ---
  drivers/mfd/88pm860x-core.c |  4 
  drivers/mfd/ab8500-core.c   |  4 
  drivers/mfd/arizona-irq.c   |  7 ---
  drivers/mfd/asic3.c |  4 ++--
  drivers/mfd/db8500-prcmu.c  |  1 -
  drivers/mfd/ezx-pcap.c  |  6 +-
  drivers/mfd/htc-egpio.c |  4 ++--
  drivers/mfd/htc-i2cpld.c|  6 +-
  drivers/mfd/lp8788-irq.c|  5 -
  drivers/mfd/max8925-core.c  |  5 +
  drivers/mfd/max8997-irq.c   |  5 +
  drivers/mfd/max8998-irq.c   |  5 +
  drivers/mfd/mt6397-core.c   |  4 
  drivers/mfd/pm8921-core.c   |  5 +
  drivers/mfd/rc5t583-irq.c   |  4 +---
  drivers/mfd/stmpe.c |  7 ---
  drivers/mfd/t7l66xb.c   |  6 --
  drivers/mfd/tc3589x.c   |  7 ---
  drivers/mfd/tc6393xb.c  |  4 ++--
  drivers/mfd/tps6586x.c  |  7 ---
  drivers/mfd/tps65912-irq.c  |  8 +---
  drivers/mfd/twl4030-irq.c   | 11 +--
  drivers/mfd/twl6030-irq.c   | 13 -
  drivers/mfd/ucb1x00-core.c  |  2 +-
  drivers/mfd/wm831x-irq.c|  7 ---
  drivers/mfd/wm8350-irq.c|  8 +---
  drivers/mfd/wm8994-irq.c|  7 ---
  27 files changed, 17 insertions(+), 139 deletions(-)

Acked-by: Lee Jones lee.jo...@linaro.org

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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


[PATCH] Revert ARM: dts: am335x-boneblack: disable RTC-only sleep

2015-06-11 Thread Johan Hovold
This reverts commit 3d76be5b933e2a66d85a2f7444e68e99e8a48ad4.

The latest revision of Beaglebone Black does not support RTC-only mode.

To avoid potential hardware damage, RTC-only mode was disabled by
default by commit 7a6cb0abe1aa (ARM: dts: am335x-boneblack: disable
RTC-only sleep to avoid hardware damage).

Unfortunately, an incorrect fix had already been applied, which instead
of just disabling RTC-only mode, prevents the Beaglebone from powering
down at all.

Revert this patch to fix the power-off regression.

Signed-off-by: Johan Hovold jo...@kernel.org
---

The offending patch was incorrectly applied after Matthijs initial fix
was posted and before the final fix (which only added some comments) was
applied.

Note that the final version of the fix 7a6cb0abe1aa (ARM: dts:
am335x-boneblack: disable RTC-only sleep to avoid hardware damage)
indicates that it should be backported to 3.12 even though RTC-only mode
was first enabled in 3.19.

Johan


 arch/arm/boot/dts/am335x-boneblack.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index 901739fcb85a..5c42d259fa68 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -80,3 +80,7 @@
status = okay;
};
 };
+
+rtc {
+   system-power-controller;
+};
-- 
2.3.6

--
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


Re: EDMA oftree entry for AM335x

2015-06-11 Thread Peter Ujfalusi
On 06/11/2015 05:13 PM, Tony Lindgren wrote:
 Well, I was not.
 But I'm now ;)
 
 OK good to hear!

I have a working version now, but...
Due to the scale of the needed changes we would need different compatible
string for the single hwmod version.
The Linux driver itself works fine if I don't change the compatible
(ti,edma3). Boots fine with the old and new DTS file, but the edma sections
are not compatible anymore IMO.

I don't want to rush in a new binding for it since I want to make sure that
the new binding will be usable when I got the chance to rewrite the edma stack
(get rid of the code from arch/arm/common/edma.c)

We have the xbar support embedded in the current edma driver - not the same
crossbar as we have in dra7, it is a bit more problematic (very problematic).
Currently we do not have support for more than one TPCC via DT, legacy boot on
SoC with more than one TPCC is also going to be interesting.

Since we will need new bindings for the edma when we fix the multiple hwmods I
think we should allow us some time to think about it a bit and come up with
something which will work in the future and it is nice to look at it at the
same time ;)

And I will be away for one week...
If you want I can send an RFC/DO NOT MERGE series with the code I have
tomorrow in case you want to see it, but I think it will look quite a bit
different at the end.

-- 
Péter
--
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


Re: EDMA oftree entry for AM335x

2015-06-11 Thread Tony Lindgren
* Peter Ujfalusi peter.ujfal...@ti.com [150610 04:18]:
 On 06/10/2015 08:10 AM, Tony Lindgren wrote:
  * Robert Schwebel r.schwe...@pengutronix.de [150608 04:01]:
  On Wed, May 06, 2015 at 07:39:52AM -0700, Tony Lindgren wrote:
 
  That may never happen considering that davinci is using it too.. It's
  best to not count on that happening anytime soon at least.
 
  So my current understanding is that we have the situation that the
  kernel warns about the oftree being wrong, but isn't able to handle an
  oftree that would be right.
 
  Shouldn't the warning being added when the kernel driver supports that
  new mechanism?
  
  This particular driver is broken and it needs to be fixed properly.
   
  I had a warning free mainline kernel without patches on my customer
  hardware before, so this smells a bit like a regression ... :-/
  
  Yes sorry I'm not patching away the warning as it does not fix the
  driver. Peter, I assume you are busy fixing it?
 
 Well, I was not.
 But I'm now ;)

OK good to hear!

Tony
--
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


Re: [PATCH 08/15] memory: kill off set_irq_flags usage

2015-06-11 Thread Roger Quadros
On Thu, 11 Jun 2015 08:17:45 -0500
Rob Herring r...@kernel.org wrote:

 On Thu, Jun 11, 2015 at 7:18 AM, Roger Quadros rog...@ti.com wrote:
  Rob,
 
  On Tue, 9 Jun 2015 13:26:34 -0500
  Rob Herring r...@kernel.org wrote:
 
  set_irq_flags is ARM specific with custom flags which have genirq
  equivalents. Convert drivers to use the genirq interfaces directly, so we
  can kill off set_irq_flags. The translation of flags is as follows:
 
  IRQF_VALID - !IRQ_NOREQUEST
  IRQF_PROBE - !IRQ_NOPROBE
  IRQF_NOAUTOEN - IRQ_NOAUTOEN
 
  For IRQs managed by an irqdomain, the irqdomain core code handles clearing
  and setting IRQ_NOREQUEST already, so there is no need to do this in
  .map() functions and we can simply remove the set_irq_flags calls. Some
  users also set IRQ_NOPROBE and this has been maintained although it is not
  clear that is really needed. There appears to be a great deal of blind
  copy and paste of this code.
 
  Signed-off-by: Rob Herring r...@kernel.org
  Cc: Roger Quadros rog...@ti.com
  Cc: Tony Lindgren t...@atomide.com
  Cc: linux-omap@vger.kernel.org
  ---
   drivers/memory/omap-gpmc.c | 5 ++---
   1 file changed, 2 insertions(+), 3 deletions(-)
 
  diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
  index c94ea0d..0c833e2 100644
  --- a/drivers/memory/omap-gpmc.c
  +++ b/drivers/memory/omap-gpmc.c
  @@ -1176,8 +1176,8 @@ static int gpmc_setup_irq(void)
gpmc_client_irq[i].irq = gpmc_irq_start + i;
irq_set_chip_and_handler(gpmc_client_irq[i].irq,
gpmc_irq_chip, handle_simple_irq);
  - set_irq_flags(gpmc_client_irq[i].irq,
  - IRQF_VALID | IRQF_NOAUTOEN);
  + irq_modify_status(gpmc_client_irq[i].irq, IRQ_NOREQUEST,
  +   IRQ_NOAUTOEN);
 
  Shouldn't this be
  irq_modify_status(gpmc_client_irq[i].irq, IRQ_NOREQUEST,
IRQ_NOAUTOEN | IRQ_NOPROBE);
  ?
 
 Only if this needs to work on !ARM. The default for ARM is IRQ_NOPROBE set.

OK. In that case.

Acked-by: Roger Quadros rog...@ti.com

cheers,
-roger
--
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


[PATCH stable/3.18.y] ARM: OMAP3: Fix booting with thumb2 kernel

2015-06-11 Thread Kevin Hilman
From: Tony Lindgren t...@atomide.com

We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:

Internal error: Oops: 8005 [#1] SMP THUMB2
...
[c046497b] (_raw_spin_unlock_irqrestore) from [c0024375]
(omap3_enter_idle_bm+0xc5/0x178)
[c0024375] (omap3_enter_idle_bm) from [c0374e63]
(cpuidle_enter_state+0x77/0x27c)
[c0374e63] (cpuidle_enter_state) from [c00627f1]
(cpu_startup_entry+0x155/0x23c)
[c00627f1] (cpu_startup_entry) from [c06b9a47]
(start_kernel+0x32f/0x338)
[c06b9a47] (start_kernel) from [8000807f] (0x8000807f)

The power management related assembly on omaps needs to interact with
ARM mode bootrom code, so we need to keep most of the related assembly
in ARM mode.

Turns out this error is because of missing ENDPROC for assembly code
as suggested by Stephen Boyd sb...@codeaurora.org. Let's fix the
problem by adding ENDPROC in two places to sleep34xx.S.

Let's also remove the now duplicate custom code for mode switching.
This has been unnecessary since commit 6ebbf2ce437b (ARM: convert
all mov.* pc, reg to bx reg for ARMv6+).

And let's also remove the comments about local variables, they are
now just confusing after the ENDPROC.

The reason why ENDPROC makes a difference is it sets .type and then
the compiler knows what to do with the thumb bit as explained at:

https://wiki.ubuntu.com/ARM/Thumb2PortingHowto

Reported-by: Kevin Hilman khil...@kernel.org
Tested-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Tony Lindgren t...@atomide.com
(cherry picked from commit d8a50941c91a68da202aaa96a3dacd471ea9c693)
Cc: sta...@vger.kernel.org # v3.18+
Signed-off-by: Kevin Hilman khil...@linaro.org
---
Sasha, please add to your v3.18.y-queue.  This one fixes boot failures
on several ARM/OMAP platforms when CONFIG_THUMB2_KERNEL=y.

 arch/arm/mach-omap2/sleep34xx.S | 22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index d1dedc8195ed..eafd120b53f1 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -203,23 +203,8 @@ save_context_wfi:
 */
ldr r1, kernel_flush
blx r1
-   /*
-* The kernel doesn't interwork: v7_flush_dcache_all in particluar will
-* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
-* This sequence switches back to ARM.  Note that .align may insert a
-* nop: bx pc needs to be word-aligned in order to work.
-*/
- THUMB(.thumb  )
- THUMB(.align  )
- THUMB(bx  pc  )
- THUMB(nop )
-   .arm
-
b   omap3_do_wfi
-
-/*
- * Local variables
- */
+ENDPROC(omap34xx_cpu_suspend)
 omap3_do_wfi_sram_addr:
.word omap3_do_wfi_sram
 kernel_flush:
@@ -364,10 +349,7 @@ exit_nonoff_modes:
  * ===
  */
ldmfd   sp!, {r4 - r11, pc} @ restore regs and return
-
-/*
- * Local variables
- */
+ENDPROC(omap3_do_wfi)
 sdrc_power:
.word   SDRC_POWER_V
 cm_idlest1_core:
-- 
2.3.1

--
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


Re: [RFC PATCH] usb: dwc3: ep0: Fix mem corruption on OUT transfers of more than 512 bytes

2015-06-11 Thread Michael Trimarchi
Hi

On Tue, Jun 9, 2015 at 3:44 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
 Hi,

 On Tuesday 09 June 2015 08:09 PM, Michael Trimarchi wrote:

 Hi

 On Jun 9, 2015 4:36 PM, Kishon Vijay Abraham I kis...@ti.com
 mailto:kis...@ti.com wrote:
  
   DWC3 uses bounce buffer to handle non max packet aligned OUT transfers
 and
   the size of bounce buffer is 512 bytes. However if the host initiates
 OUT
   transfers of size more than 512 bytes (and non max packet aligned), the
   driver throws a WARN dump but still programs the TRB to receive more
 than
   512 bytes. This will cause bounce buffer to overflow and corrupt the
   adjacent memory locations which can be fatal.
  
   Fix it by programming the TRB to receive a maximum of
 DWC3_EP0_BOUNCE_SIZE
   (512) bytes.
  
   Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 mailto:kis...@ti.com

   ---
   Steps to see the issue (before this patch)
   1) Insert g_zero in DUT
   2) run './testusb -t 14 -c 1 -s 520 -v 1' in host (size should be 
 512)
  
   The test should FAIL since bounce buffer can handle only 512 bytes, but
 the
   test PASS. There is a WARN dump in DUT but still there will be memory
   corruption since the bounce buffer overflows.
  
   Tested this patch using USB3 Gen X CV (ch9 tests: usb2 and usb3, link
 layer
   testing and MSC tests) and using USB2 X CV (ch9 tests, MSC tests).
  
   After the patch, the tests timeout!
   ./testusb -t 14 -c 1 -s 514 -v 1
   unknown speed   /dev/bus/usb/001/0180
   /dev/bus/usb/001/018 test 14 -- 110 (Connection timed out)
  
   IMO a patch to fix this is required for stable releases too. So If this
   patch is alright, I can post the patch cc'ing stable. While the actual
 fix
   would be to have chained TRB, I'm not sure if it can go to stable
   releases.
drivers/usb/dwc3/ep0.c |   12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
  
   diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
   index 2ef3c8d..8858c60 100644
   --- a/drivers/usb/dwc3/ep0.c
   +++ b/drivers/usb/dwc3/ep0.c
   @@ -816,6 +816,11 @@ static void dwc3_ep0_complete_data(struct dwc3
 *dwc,
   unsigned maxp = ep0-endpoint.maxpacket;
  
   transfer_size += (maxp - (transfer_size % maxp));
   +
   +   /* Maximum of DWC3_EP0_BOUNCE_SIZE can only be received
 */
   +   if (transfer_size  DWC3_EP0_BOUNCE_SIZE)
   +   transfer_size = DWC3_EP0_BOUNCE_SIZE;
   +

 Can you just use maxp in the correct way?


 what do you mean by correct way? Using roundup() to calculate transfer_size?


just a max

Michael

 Thanks
 Kishon



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
--
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


Re: [PATCH 08/15] memory: kill off set_irq_flags usage

2015-06-11 Thread Roger Quadros
Rob,

On Tue, 9 Jun 2015 13:26:34 -0500
Rob Herring r...@kernel.org wrote:

 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:
 
 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN
 
 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also set IRQ_NOPROBE and this has been maintained although it is not
 clear that is really needed. There appears to be a great deal of blind
 copy and paste of this code.
 
 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Roger Quadros rog...@ti.com
 Cc: Tony Lindgren t...@atomide.com
 Cc: linux-omap@vger.kernel.org
 ---
  drivers/memory/omap-gpmc.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
 index c94ea0d..0c833e2 100644
 --- a/drivers/memory/omap-gpmc.c
 +++ b/drivers/memory/omap-gpmc.c
 @@ -1176,8 +1176,8 @@ static int gpmc_setup_irq(void)
   gpmc_client_irq[i].irq = gpmc_irq_start + i;
   irq_set_chip_and_handler(gpmc_client_irq[i].irq,
   gpmc_irq_chip, handle_simple_irq);
 - set_irq_flags(gpmc_client_irq[i].irq,
 - IRQF_VALID | IRQF_NOAUTOEN);
 + irq_modify_status(gpmc_client_irq[i].irq, IRQ_NOREQUEST,
 +   IRQ_NOAUTOEN);

Shouldn't this be
irq_modify_status(gpmc_client_irq[i].irq, IRQ_NOREQUEST,
  IRQ_NOAUTOEN | IRQ_NOPROBE);
?

   }
  
   /* Disable interrupts */
 @@ -1200,7 +1200,6 @@ static int gpmc_free_irq(void)
   for (i = 0; i  GPMC_NR_IRQ; i++) {
   irq_set_handler(gpmc_client_irq[i].irq, NULL);
   irq_set_chip(gpmc_client_irq[i].irq, no_irq_chip);
 - irq_modify_status(gpmc_client_irq[i].irq, 0, 0);
   }
  
   irq_free_descs(gpmc_irq_start, GPMC_NR_IRQ);

cheers,
-roger
--
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


Re: [PATCH 08/15] memory: kill off set_irq_flags usage

2015-06-11 Thread Rob Herring
On Thu, Jun 11, 2015 at 7:18 AM, Roger Quadros rog...@ti.com wrote:
 Rob,

 On Tue, 9 Jun 2015 13:26:34 -0500
 Rob Herring r...@kernel.org wrote:

 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:

 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN

 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also set IRQ_NOPROBE and this has been maintained although it is not
 clear that is really needed. There appears to be a great deal of blind
 copy and paste of this code.

 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Roger Quadros rog...@ti.com
 Cc: Tony Lindgren t...@atomide.com
 Cc: linux-omap@vger.kernel.org
 ---
  drivers/memory/omap-gpmc.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

 diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
 index c94ea0d..0c833e2 100644
 --- a/drivers/memory/omap-gpmc.c
 +++ b/drivers/memory/omap-gpmc.c
 @@ -1176,8 +1176,8 @@ static int gpmc_setup_irq(void)
   gpmc_client_irq[i].irq = gpmc_irq_start + i;
   irq_set_chip_and_handler(gpmc_client_irq[i].irq,
   gpmc_irq_chip, handle_simple_irq);
 - set_irq_flags(gpmc_client_irq[i].irq,
 - IRQF_VALID | IRQF_NOAUTOEN);
 + irq_modify_status(gpmc_client_irq[i].irq, IRQ_NOREQUEST,
 +   IRQ_NOAUTOEN);

 Shouldn't this be
 irq_modify_status(gpmc_client_irq[i].irq, IRQ_NOREQUEST,
   IRQ_NOAUTOEN | IRQ_NOPROBE);
 ?

Only if this needs to work on !ARM. The default for ARM is IRQ_NOPROBE set.

Rob
--
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


Re: [GIT PULL 2/3] omap defconfig changes for v4.2

2015-06-11 Thread Kevin Hilman
Tony Lindgren t...@atomide.com writes:

 The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:

   Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v4.2/o2_dc

 for you to fetch changes up to 4cbb08336f506cde30c0dfb3e49c55a52842fb5c:

   ARM: omap2plus_defconfig: Enable TOUCHSCREEN_PIXCIR (2015-06-02 07:54:50 
 -0700)

 
 Few omap2plus_defconfig changes for v4.2 merge window:

 - Enable dm9000 as built-in for NFSroot

 - Enable dm816x USB phy as a loadable module

 - Enable Pixcir touch screen as a loadable module

 

Pulled into next/defconfig.

Thanks,

Kevin
--
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


Re: [GIT PULL 1/3] omap device tree changes for v4.2, part 2

2015-06-11 Thread Kevin Hilman
Tony Lindgren t...@atomide.com writes:

 The following changes since commit 52dfcbfc94833b0192d439127ee9ff46023cdbb2:

   ARM: dts: am335x-evm: add mmc3 and wlan definitions to dts (2015-05-21 
 12:05:59 -0700)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v4.2/dt-pt2

 for you to fetch changes up to 8584d4fcabe2501e1c95b4d063cd4a76891d:

   ARM: dts: am335x-sl50: Add Toby-Churchill SL50 board support. (2015-05-28 
 09:49:50 -0700)

 
 Few more omap device tree changes for v4.2 merge window:

 - Add dm9000 Ethernet support to omap3-devkit8000

 - Add Toby-Churchill SL50 board support

 - Add vendor prefix for Toby Churchill Ltd

 

Pulled into next/dt.

Thanks,

Kevin
--
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