Will,
On Wednesday 13 March 2013 05:59 PM, Lokesh Vutla wrote:
> Hi Dietmar,
> On Wednesday 13 March 2013 05:35 PM, Dietmar Eggemann wrote:
>> On 13/03/13 06:52, Lokesh Vutla wrote:
>>> Commit {9a6eb31 ARM: hw_breakpoint: Debug powerdown support for
>>> self-hosted
>>> debug} introduces debug powe
On Wednesday 13 March 2013 09:48 PM, Mark Rutland wrote:
> On Wed, Mar 13, 2013 at 03:44:03PM +, Santosh Shilimkar wrote:
>> On Wednesday 13 March 2013 05:55 PM, Mark Rutland wrote:
>>> On Wed, Mar 13, 2013 at 11:24:01AM +, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 03:46 PM,
On Mon, 2013-03-11 at 09:33 -0700, Tony Lindgren wrote:
> * Paul Bolle [130309 11:52]:
> > In the meantime, how do you prefer I solve the (trivial) issue of an
> > useless select for MACH_NOKIA_RM696? Drop that select or add an (equally
> > useless) config entry for MACH_NOKIA_RM696? Or should I t
On Wed, Mar 13, 2013 at 10:34 PM, Anna, Suman wrote:
>> On Wed, Mar 13, 2013 at 4:24 AM, Suman Anna wrote:
>>
>> > From: Omar Ramirez Luna
>> (...)
>> >
>> > Signed-off-by: Omar Ramirez Luna
>> > [s-a...@ti.com: Kconfig fixes for build errors]
>> > Signed-off-by: Suman Anna
>> > Acked-by: Tony
On 03/13/2013 11:33 PM, Andrew Chew wrote:
> Many backlights are enabled via GPIO. We can generalize the GPIO to a
> fixed regulator.
>
> The enable regulator needs to be mandatory because there was no good way
> to determine the difference between opting out of the regulator, and probe
> deferra
On Thu, 14 Mar 2013, Santosh Shilimkar wrote:
> On Wednesday 13 March 2013 09:48 PM, Mark Rutland wrote:
> > On Wed, Mar 13, 2013 at 03:44:03PM +, Santosh Shilimkar wrote:
> >> On Wednesday 13 March 2013 05:55 PM, Mark Rutland wrote:
> >>> On Wed, Mar 13, 2013 at 11:24:01AM +, Santosh Shil
On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
> Sorry ... this just locks up the unit.
OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
below. The patch I proposed did not get the error path correctly, but it
does fix the issue.
I think what you treat as "lockup" is
(Looping Greg KH.)
Greg,
On Wednesday 20 February 2013 09:14 PM, Santosh Shilimkar wrote:
> On Wednesday 20 February 2013 08:54 PM, Kevin Hilman wrote:
>> Santosh Shilimkar writes:
>>
>>> UART IP slave idle handling now taken care by runtime pm backend(hwmod
>>> layer)
>>> so remove the hackery
On 14/03/13 09:13, Artem Bityutskiy wrote:
> On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
>> Sorry ... this just locks up the unit.
>
> OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
> below. The patch I proposed did not get the error path correctly, but it
> does
On 3/13/2013 3:04 PM, Mark Jackson wrote:
On 18/02/13 08:19, Mugunthan V N wrote:
>CPDMA interrupts are not properly acknowledged which leads to interrupt
>storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
>Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which a
On 14/03/13 10:21, Mugunthan V N wrote:
> On 3/13/2013 3:04 PM, Mark Jackson wrote:
>> On 18/02/13 08:19, Mugunthan V N wrote:
>>> >CPDMA interrupts are not properly acknowledged which leads to interrupt
>>> >storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
>>> >Changed cpdma_
On Thu, Mar 14, 2013 at 07:45:14AM +, Santosh Shilimkar wrote:
> On Wednesday 13 March 2013 09:48 PM, Mark Rutland wrote:
> > On Wed, Mar 13, 2013 at 03:44:03PM +, Santosh Shilimkar wrote:
> >> On Wednesday 13 March 2013 05:55 PM, Mark Rutland wrote:
> >>> On Wed, Mar 13, 2013 at 11:24:01AM
On Thu, 2013-03-14 at 09:54 +, Mark Jackson wrote:
> On 14/03/13 09:13, Artem Bityutskiy wrote:
> > On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
> >> Sorry ... this just locks up the unit.
> >
> > OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
> > below. The p
Hello guys,
This is v2 of my patch https://patchwork.kernel.org/patch/1232871/
rebased on v3.9-rc2. Removes deprecated flags and structures
and saves few bytes of memory.
Regards,
Ruslan
Ruslan Bilovol (1):
omap: usb: host: remove deprecated flags and structures
include/linux/platform_data/u
These flags and structures are deprecated and there is
no anymore users of them, so it's safe to remove them.
Signed-off-by: Ruslan Bilovol
---
include/linux/platform_data/usb-omap.h | 20
1 file changed, 20 deletions(-)
diff --git a/include/linux/platform_data/usb-omap.h
On Thursday 14 March 2013 03:58 PM, Mark Rutland wrote:
> On Thu, Mar 14, 2013 at 07:45:14AM +, Santosh Shilimkar wrote:
>> On Wednesday 13 March 2013 09:48 PM, Mark Rutland wrote:
>>> On Wed, Mar 13, 2013 at 03:44:03PM +, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 05:55 PM, M
Used of_platform_populate() to create dwc3 core platform_device
from device tree data. Additionally some cleanup is also done.
Signed-off-by: Vivek Gautam
CC: Felipe Balbi
CC: Kukjin Kim
---
drivers/usb/dwc3/dwc3-exynos.c | 46 +---
1 files changed, 15 ins
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
calls as required by common clock framework.
Signed-off-by: Vivek Gautam
CC: Felipe Balbi
CC: Kukjin Kim
---
drivers/usb/dwc3/dwc3-exynos.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/d
This patch-set modifies dwc3-exynos as per latest bindings
available for dwc3. Now the dwc3 core also has device support,
there's no need to add platform device for core in glue layers.
This change has come as a result of discussion happened in:
[PATCH RFC] usb: dwc3: Get PHY from platform specific
Hi,
On Thu, Mar 14, 2013 at 04:14:57PM +0530, Vivek Gautam wrote:
> @@ -170,7 +155,6 @@ static int dwc3_exynos_remove(struct platform_device
> *pdev)
> {
> struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
>
> - platform_device_unregister(exynos->dwc3);
don't you want to
Hi,
On Thu, Mar 14, 2013 at 04:14:58PM +0530, Vivek Gautam wrote:
> Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
> calls as required by common clock framework.
>
> Signed-off-by: Vivek Gautam
> CC: Felipe Balbi
> CC: Kukjin Kim
> ---
> drivers/usb/dwc3/dwc3-exyno
On Fri, Mar 08, 2013 at 11:37:17AM -0700, Stephen Warren wrote:
> On 03/08/2013 11:26 AM, Felipe Balbi wrote:
> > On Fri, Mar 08, 2013 at 10:14:11AM -0700, Stephen Warren wrote:
> >> On 03/08/2013 12:14 AM, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Thu, Mar 07, 2013 at 02:20:36PM -0700, Stephen
On 14/03/13 10:30, Artem Bityutskiy wrote:
> On Thu, 2013-03-14 at 09:54 +, Mark Jackson wrote:
>> On 14/03/13 09:13, Artem Bityutskiy wrote:
>>> On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
Sorry ... this just locks up the unit.
>>>
>>> OK, I've reproduced the issue with 3.9-rc2
On Thu, 2013-03-14 at 11:15 +, Mark Jackson wrote:
> [ 28.538525] [d08ea004] *pgd=8f045811, *pte=, *ppte=
> [ 28.545173] Internal error: Oops: 7 [#1] ARM
> [ 28.549685] CPU: 0Not tainted
> (3.8.0-next-20130225-2-g678576f-dirty #40)
> [ 28.557595] PC is at crc32
> -Original Message-
> From: Hiremath, Vaibhav
> Sent: Monday, March 04, 2013 5:06 PM
> To: linux-omap@vger.kernel.org
> Cc: t...@atomide.com; khil...@linaro.org; p...@pwsan.com; Nayak,
> Rajendra; linux-arm-ker...@lists.infradead.org; Hiremath, Vaibhav
> Subject: [RFC PATCH 0/3] ARM: OMAP
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Paul Walmsley
> Sent: Tuesday, March 12, 2013 10:10 PM
> To: linux-omap@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Subject: OMAP baseline test results f
On Thursday 14 March 2013 04:59 PM, Hiremath, Vaibhav wrote:
>
>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>> ow...@vger.kernel.org] On Behalf Of Paul Walmsley
>> Sent: Tuesday, March 12, 2013 10:10 PM
>> To: linux-omap@vger.kernel.org
>> Cc: linux-a
On 14/03/13 11:23, Artem Bityutskiy wrote:
> On Thu, 2013-03-14 at 11:15 +, Mark Jackson wrote:
>> [ 28.538525] [d08ea004] *pgd=8f045811, *pte=, *ppte=
>> [ 28.545173] Internal error: Oops: 7 [#1] ARM
>> [ 28.549685] CPU: 0Not tainted
>> (3.8.0-next-20130225-2-g6
On Thu, Mar 14, 2013 at 4:21 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Mar 14, 2013 at 04:14:57PM +0530, Vivek Gautam wrote:
>> @@ -170,7 +155,6 @@ static int dwc3_exynos_remove(struct platform_device
>> *pdev)
>> {
>> struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
>>
>> -
On Thu, 2013-03-14 at 12:02 +, Mark Jackson wrote:
> But there's also a call to crc with a size of 122880 bytes, and that's
> when the oops occurs.
>
This is when we do the atomic LEB change.
> Is this size larger than the allocated buffer ?
I believe so.
--
Best Regards,
Artem Bityutskiy
On Thu, 2013-03-14 at 14:18 +0200, Artem Bityutskiy wrote:
> > Is this size larger than the allocated buffer ?
>
> I believe so.
Err, I mean, the buffer is large enough. I do not believe there is a
stupid bug like too small buffer. This code has worked for years and I
do not think it was changes
These patches mainly fix the crash that was reported with
CONFIG_DEBUG_SLAB enabled on OMAPs, due to the early clock
initializations.
Tested on Panda ES (omap4460), beagle Xm (omap3630) and
BeagleBoneBlack (AM335x)
Rajendra Nayak (2):
ARM: OMAP2+: clocks: Have consistent naming for parent name
OMAP clock inits happen quite early, even before the slab is available.
As part of the clock init, the common clock core tries to cache parent
pointers (if not passed by the caller registering the clock) which
fails in case of OMAP since the slab isn't initied.
Without CONFIG_DEBUG_SLAB enabled, th
Used of_platform_populate() to create dwc3 core platform_device
from device tree data. Additionally some cleanup is also done.
Signed-off-by: Vivek Gautam
CC: Felipe Balbi
CC: Kukjin Kim
---
Changes from v1:
- Added method to unregister dwc3 core from dwc3_exynos_remove()
using device_for_
Missed out Mike, copied now.
On Thursday 14 March 2013 06:06 PM, Rajendra Nayak wrote:
> These patches mainly fix the crash that was reported with
> CONFIG_DEBUG_SLAB enabled on OMAPs, due to the early clock
> initializations.
>
> Tested on Panda ES (omap4460), beagle Xm (omap3630) and
> BeagleBo
On Thu, Mar 14, 2013 at 12:41:13PM +0200, Ruslan Bilovol wrote:
> These flags and structures are deprecated and there is
> no anymore users of them, so it's safe to remove them.
>
> Signed-off-by: Ruslan Bilovol
Acked-by: Felipe Balbi
--
balbi
signature.asc
Description: Digital signature
On Thu, Mar 14, 2013 at 11:53:55AM +0530, Kishon Vijay Abraham I wrote:
> This series has some misc cleanup and fixes. The fix solves the cold
> plug issue in omap3 which some have reported. Developed these patches on
> fixes-for-v3.9-rc3 after applying
> http://www.spinics.net/lists/linux-usb/msg
On 14/03/13 13:40, Mark Jackson wrote:
> On 14/03/13 12:23, Artem Bityutskiy wrote:
>> On Thu, 2013-03-14 at 14:18 +0200, Artem Bityutskiy wrote:
Is this size larger than the allocated buffer ?
>>>
>>> I believe so.
>>
>> Err, I mean, the buffer is large enough. I do not believe there is a
>>
On Thu, Mar 07, 2013 at 06:51:45PM +0530, Kishon Vijay Abraham I wrote:
> From: Graeme Gregory
>
> This is the driver for the OTG transceiver built into the Palmas chip. It
> handles the various USB OTG events that can be generated by cable
> insertion/removal.
>
> Signed-off-by: Graeme Gregory
On Thu, Mar 07, 2013 at 06:51:46PM +0530, Kishon Vijay Abraham I wrote:
> No functional change. Replace *_* with *-* in property names of otg to
> follow the general convention.
>
> Signed-off-by: Kishon Vijay Abraham I
this has been pending for quite a while, since nobody complained, I'm
taking
On Tue, Mar 12, 2013 at 12:25:37PM +0200, Roger Quadros wrote:
> The helper functions omap_usbhs_rev1_hostconfig()
> and omap_usbhs_rev2_hostconfig() don't write into
> the hostconfig register. Make sure that we write
> the return value into the hostconfig register.
>
> Signed-off-by: Roger Quadro
On 14/03/13 12:23, Artem Bityutskiy wrote:
> On Thu, 2013-03-14 at 14:18 +0200, Artem Bityutskiy wrote:
>>> Is this size larger than the allocated buffer ?
>>
>> I believe so.
>
> Err, I mean, the buffer is large enough. I do not believe there is a
> stupid bug like too small buffer. This code has
On Tue, Mar 12, 2013 at 11:57:56AM -0400, Alan Stern wrote:
> On Tue, 12 Mar 2013, Roger Quadros wrote:
>
> > Even when not in PHY mode, the USB device on the port (e.g. HUB)
> > might need resources like RESET which can be modelled as a PHY
> > device. So try to get the PHY device in any case.
>
On Thursday 14 March 2013 07:03 PM, Felipe Balbi wrote:
On Thu, Mar 14, 2013 at 11:53:55AM +0530, Kishon Vijay Abraham I wrote:
This series has some misc cleanup and fixes. The fix solves the cold
plug issue in omap3 which some have reported. Developed these patches on
fixes-for-v3.9-rc3 after a
On Thu, Mar 14, 2013 at 08:15:00PM +0530, kishon wrote:
> On Thursday 14 March 2013 07:03 PM, Felipe Balbi wrote:
> >On Thu, Mar 14, 2013 at 11:53:55AM +0530, Kishon Vijay Abraham I wrote:
> >>This series has some misc cleanup and fixes. The fix solves the cold
> >>plug issue in omap3 which some ha
On Thursday 14 March 2013 08:17 PM, Felipe Balbi wrote:
On Thu, Mar 14, 2013 at 08:15:00PM +0530, kishon wrote:
On Thursday 14 March 2013 07:03 PM, Felipe Balbi wrote:
On Thu, Mar 14, 2013 at 11:53:55AM +0530, Kishon Vijay Abraham I wrote:
This series has some misc cleanup and fixes. The fix s
On Thursday 14 March 2013 07:26 PM, Felipe Balbi wrote:
On Thu, Mar 07, 2013 at 06:51:45PM +0530, Kishon Vijay Abraham I wrote:
From: Graeme Gregory
This is the driver for the OTG transceiver built into the Palmas chip. It
handles the various USB OTG events that can be generated by cable
inser
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>
> The DMA, PMU and OMAP3430 SDP board changes have been sent before
> individually but re-sending here as a complete series for v3.10.
>
> This is based upon v3.9-rc1 an
On Thu, 14 Mar 2013, Felipe Balbi wrote:
> > > if (IS_ERR(phy) || !phy) {
> > > + /* Don't bail out if PHY is not absolutely necessary */
> > > + if (pdata->port_mode[i] != OMAP_EHCI_PORT_MODE_PHY)
> > > + continue;
> > > +
> > >
Hello Jon,
As discussed before [1], this patch-set adds DT support for ethernet
controllers connected to a TI GPMC by making gpmc_probe_nor_child()
a generic function and reusing it to initialize "ethernet" child
devices nodes too. It also adds documentation about the DT binding.
The patch-set is
gpmc_probe_nor_child() calls of_platform_device_create() to create a
platform device for the NOR child. If this function fails the value
of ret is returned to the caller but this value is zero since it was
assigned the return of a previous call to gpmc_cs_program_settings()
that had to succeed or o
The gpmc_probe_nor_child() function is used in the GPMC driver to
configure the GPMC for a NOR child device node.
But this function is quite generic and all the NOR specific configuration
is made by the driver of the actual NOR flash memory used.
Other Pseudo-SRAM devices such as ethernet control
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device
On 03/13/2013 06:57 PM, Tony Lindgren wrote:
> * Roger Quadros [130313 09:40]:
>> On 03/13/2013 06:24 PM, Tony Lindgren wrote:
>>> * Roger Quadros [130313 06:46]:
On 03/12/2013 06:40 PM, Tony Lindgren wrote:
> * Roger Quadros [130312 04:47]:
>> Hi Tony,
>>
>> These patches p
On 03/11/2013 06:56 PM, Jon Hunter wrote:
>
> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
>> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
>> wrote:
>>> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter wrote:
Yes you are correct. In general, I have been trying to stay some-wh
Hi Benoit,
On 03/14/2013 03:57 PM, Benoit Cousson wrote:
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent before
individually but re-sending here as a complete
On Thu, Mar 14, 2013 at 11:53:57AM +0530, Kishon Vijay Abraham I wrote:
> Used devres APIs devm_request_threaded_irq and devm_regulator_get for
> requesting irq and for getting regulator respectively.
>
> Signed-off-by: Kishon Vijay Abraham I
please refresh this on top of my testing branch, you
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
> Besides being used to interface with external memory devices,
> the General-Purpose Memory Controller can be used to connect
> Pseudo-SRAM devices such as ethernet controllers to OMAP2+
> processors using the TI GPMC as a data bu
On Thu, Mar 14, 2013 at 11:53:59AM +0530, Kishon Vijay Abraham I wrote:
> Having twl4030_usb_phy_init() (detects if a cable is connected before
> twl4030 is probed) in twl4030 probe makes cable connect events to be
> missed by musb glue, since it gets loaded after twl4030. Having
> twl4030_usb_phy_
On 03/14/2013 12:41 PM, Ruslan Bilovol wrote:
> These flags and structures are deprecated and there is
> no anymore users of them, so it's safe to remove them.
>
> Signed-off-by: Ruslan Bilovol
Acked-by: Roger Quadros
Tony,
Do you prefer to take this directly or want me to queue it up for you
On 03/14/2013 10:45 AM, Benoit Cousson wrote:
> On 03/11/2013 06:56 PM, Jon Hunter wrote:
>>
>> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
>>> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
>>> wrote:
On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter wrote:
>
> Yes you are
On Thu, Mar 14, 2013 at 12:50 PM, Jon Hunter wrote:
>> Yes, I full agree with that as well. The size should be purely HW
>> related. So we should not take any assumption about the page size /
>> alignment.
>
> Ok, what is best to use? The size from hwmod structures or the size from
> the documenta
On 03/14/2013 04:50 PM, Jon Hunter wrote:
>
> On 03/14/2013 10:45 AM, Benoit Cousson wrote:
>> On 03/11/2013 06:56 PM, Jon Hunter wrote:
>>>
>>> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
wrote:
> On Fri, Mar 8, 2013 at 1
On 03/14/2013 10:45 AM, Florian Vaussard wrote:
> Hi Benoit,
>
> On 03/14/2013 03:57 PM, Benoit Cousson wrote:
>> Salut Jon,
>>
>> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>>
>>> The DMA, PMU and OMAP3430 SDP board change
On 03/14/2013 10:58 AM, Benoit Cousson wrote:
> On 03/14/2013 04:50 PM, Jon Hunter wrote:
>>
>> On 03/14/2013 10:45 AM, Benoit Cousson wrote:
>>> On 03/11/2013 06:56 PM, Jon Hunter wrote:
On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martin
Hi Florian,
On 01/28/2013 06:54 PM, Florian Vaussard wrote:
> Add device-tree support for the GPMC controller on the OMAP3.
>
> Signed-off-by: Florian Vaussard
Applied and pushed.
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.10/dts
Regards,
Benoit
--
To unsu
On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson wrote:
> Salut Jon,
>
> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>
>> The DMA, PMU and OMAP3430 SDP board changes have been sent before
>> individually but re-sending here as
On 03/14/2013 05:00 PM, Jon Hunter wrote:
>
>
> On 03/14/2013 10:58 AM, Benoit Cousson wrote:
>> On 03/14/2013 04:50 PM, Jon Hunter wrote:
>>>
>>> On 03/14/2013 10:45 AM, Benoit Cousson wrote:
On 03/11/2013 06:56 PM, Jon Hunter wrote:
>
> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote
On 03/14/2013 11:02 AM, Javier Martinez Canillas wrote:
> On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson wrote:
>> Salut Jon,
>>
>> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>>
>>> The DMA, PMU and OMAP3430 SDP board chan
On 03/14/2013 04:59 PM, Jon Hunter wrote:
>
> On 03/14/2013 10:45 AM, Florian Vaussard wrote:
>> Hi Benoit,
>>
>> On 03/14/2013 03:57 PM, Benoit Cousson wrote:
>>> Salut Jon,
>>>
>>> On 03/08/2013 06:27 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards
Hi Javier,
On 03/14/2013 05:02 PM, Javier Martinez Canillas wrote:
> On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson wrote:
>> Salut Jon,
>>
>> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>>
>>> The DMA, PMU and OMAP3430 SDP
Hi Aaro,
On Tue, 12 Mar 2013, Aaro Koskinen wrote:
> On Tue, Mar 12, 2013 at 04:40:19PM +, Paul Walmsley wrote:
> > * 2420N800: powers down 30 seconds after boot
> > - Presumably due to missing CBUS patches for watchdog control
> > - http://lkml.org/lkml/2012/9/3/265
> > - http://marc.i
On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter wrote:
> Hi Javier,
>
> On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
>> Besides being used to interface with external memory devices,
>> the General-Purpose Memory Controller can be used to connect
>> Pseudo-SRAM devices such as ethernet contr
* Roger Quadros [130314 08:45]:
>
> OK. Let me know how the below patch looks. After that, the board code
> will look like.
>
> static struct usbhs_phy_data phy_data[] = {
> {
> .reset_gpio = 147,
> .vcc_gpio = 148
> .vcc_polarity = 1,
>
On Thu, Mar 14, 2013 at 5:37 PM, Javier Martinez Canillas
wrote:
> On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter wrote:
>> Hi Javier,
>>
>> On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
>>> Besides being used to interface with external memory devices,
>>> the General-Purpose Memory Contro
* Rajendra Nayak [130314 05:44]:
> OMAP clock inits happen quite early, even before the slab is available.
> As part of the clock init, the common clock core tries to cache parent
> pointers (if not passed by the caller registering the clock) which
> fails in case of OMAP since the slab isn't init
Lokesh Vutla writes:
> Commit {9a6eb31 ARM: hw_breakpoint: Debug powerdown support for self-hosted
> debug} introduces debug powerdown support for self-hosted debug.
> While merging the patch 'has_ossr' check was removed which
> was needed for hardwares which doesn't support self-hosted debug.
>
Hi guys,
This is a resend of my patch:
http://permalink.gmane.org/gmane.linux.usb.general/67238
At this moment it has been successfully tested and
used on top of 3.0 and 3.4 kernels on omap4 devices
so it would be great to have it in upstream too.
Regards,
Ruslan
Ruslan Bilovol (1):
usb: mus
MUSB controller cannot work in DMA mode with misaligned buffers,
switching in PIO mode.
HCD core has hooks that allow to override the default DMA
mapping and unmapping routines for host controllers that have
special DMA requirements, such as alignment contraints.
It is observed that work in PIO m
> On Wed, Mar 13, 2013 at 10:34 PM, Anna, Suman wrote:
> >> On Wed, Mar 13, 2013 at 4:24 AM, Suman Anna wrote:
> >>
> >> > From: Omar Ramirez Luna
> >> (...)
> >> >
> >> > Signed-off-by: Omar Ramirez Luna
> >> > [s-a...@ti.com: Kconfig fixes for build errors]
> >> > Signed-off-by: Suman Anna
>
On 03/14/2013 11:37 AM, Javier Martinez Canillas wrote:
> On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter wrote:
>> Hi Javier,
>>
>> On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
>>> Besides being used to interface with external memory devices,
>>> the General-Purpose Memory Controller can
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
> gpmc_probe_nor_child() calls of_platform_device_create() to create a
> platform device for the NOR child. If this function fails the value
> of ret is returned to the caller but this value is zero since it was
> assigned the return of a pr
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
> The gpmc_probe_nor_child() function is used in the GPMC driver to
> configure the GPMC for a NOR child device node.
>
> But this function is quite generic and all the NOR specific configuration
> is made by the driver of the actual NOR fla
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony,
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git
tags/oma
Here are some basic OMAP test results for Linux v3.9-rc2.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc2/20130314094808/
Test summary
Build:
FAIL ( 4/16): am33xx_only, omap1_defconfig,
omap1_defconfig_5912osk_only,
On 03/14/13 03:28, Mark Rutland wrote:
> On Thu, Mar 14, 2013 at 07:45:14AM +, Santosh Shilimkar wrote:
>> On Wednesday 13 March 2013 09:48 PM, Mark Rutland wrote:
>>> On Wed, Mar 13, 2013 at 03:44:03PM +, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 05:55 PM, Mark Rutland wrote
On Thu, Mar 14, 2013 at 7:49 PM, Jon Hunter wrote:
>
> On 03/14/2013 11:37 AM, Javier Martinez Canillas wrote:
>> On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter wrote:
>>> Hi Javier,
>>>
>>> On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to interface with external me
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device
On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote:
> Besides being used to interface with external memory devices,
> the General-Purpose Memory Controller can be used to connect
> Pseudo-SRAM devices such as ethernet controllers to OMAP2+
> processors using the TI GPMC as a data bus.
>
> Thi
The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
migrating the cpufreq support only through device tree (part of the effort
to migrate away from non-DT configurations for OMAP). Unfortunately, a
Add DT OPP table for OMAP443x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman
Cc: "Benoît Cousson"
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: Keerthy
Cc: linux-omap@vger.kernel.or
With OMAP3+ and AM33xx supported SoC having defined CPU DT
entries with operating-points defined, we can now
use the SoC generic cpu0-cpufreq driver to start
using it, lets now switch to the generic driver.
As part of this change, switch the dummy clock node to use
cpufreq-cpu0. This is an suggest
Add DT OPP table for OMAP34xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman
Cc: "Benoît Cousson"
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: Keerthy
Cc: linux-omap@vger.kernel.or
Add DT OPP table for OMAP36xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function. This
overrides the default OMAP34xx CPU OPP table definition.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman
Cc: "Benoît Cousson"
Cc: Santosh Shilim
OMAP4430 and 4460 have different OPP definitions. So, create an SoC
variant dtsi file for 4460 and move the OPP definitions to it.
Add DT OPP table for OMAP446x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufre
We can now use cpufreq-cpu0 driver using DT entries.
remove the redundant omap-cpufreq driver from the tree.
Remove MAINTAINERS file entry for the same as well.
Cc: Kevin Hilman
Cc: "Benoît Cousson"
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: Keerthy
Cc: linux-omap@vger.kernel.org
Cc: devicetree-
PandaBoard, PandaBoard-A4 revisions use OMAP4430.
PandaBoard-ES version of the board uses OMAP4460.
Move the original panda dts file into a common dtsi used by all panda
variants. This allows us to introduce SoC variation for PandaBoard ES
without impacting other PandaBoard versions that are suppo
Define VDD1 regulator in twl4030 DT and mark it as the supply for the
various OMAP3 platforms.
Cc: Kevin Hilman
Cc: "Benoît Cousson"
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: Keerthy
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Javier
Hi Jon,
On 14/03/2013, at 21:43, Jon Hunter wrote:
>
> On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote:
>> Besides being used to interface with external memory devices,
>> the General-Purpose Memory Controller can be used to connect
>> Pseudo-SRAM devices such as ethernet contr
On 03/14/2013 04:08 PM, Javier Martinez Canillas wrote:
>
>
> Javier
>
> Hi Jon,
>
> On 14/03/2013, at 21:43, Jon Hunter wrote:
>
>>
>> On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote:
>>> Besides being used to interface with external memory devices,
>>> the General-Purpose Memory Con
1 - 100 of 110 matches
Mail list logo
