* Nick Krause [140701 15:51]:
> Hey Tony and Russel ,
> There is a FIX ME message in this function of the file stated in my
> subject line.
> I was wondering what locking is needed here due to not having experience with
> omap subsystem(s).
Looks like the locking for ocpi_enable would be needed
>From: Ezequiel García [mailto:ezequ...@vanguardiasur.com.ar]
>>On 26 Jun 12:02 PM, Guido Martínez wrote:
>> Currently, child nodes of the gpmc node are iterated and probed
>> regardless of their 'status' property. This means adding 'status =
>> "disabled";' has no effect.
>>
>> This patch changes
>From: Guido Martínez [mailto:gu...@vanguardiasur.com.ar]
>>On Tue, Jul 01, 2014 at 07:01:03AM +, Gupta, Pekon wrote:
>> >http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
>> >
>> I don't think we need above patch.
>> Helper macro "for_each_available_child_of_node" int
On Monday 30 June 2014 09:27 PM, Nishanth Menon wrote:
Hi,
Original thread (v1): http://marc.info/?t=14038076654&r=1&w=2
This series is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
branch: topic/palmas (4c0c9ca Merge remote-tracking branch
'regulator
Quoting Peter Ujfalusi (2014-06-26 23:01:09)
> Hi Mike,
>
> This is a resend of the v2 version of the palmas clock driver which seamingly
> missed the 3.16 merge window. I have added Nishanth's Reviewed-by tag to the
> patches.
Thanks for the resend. Applied to clk-next.
Regards,
Mike
>
> Chan
Quoting Peter Ujfalusi (2014-06-29 22:56:55)
> Hi Javier,
>
> On 06/27/2014 09:23 PM, Javier Martinez Canillas wrote:
> > Hello Peter,
> >
> > On Fri, Jun 27, 2014 at 8:01 AM, Peter Ujfalusi
> > wrote:
> >> Palmas class of devices can provide 32K clock(s) to be used by other
> >> devices
> >>
On 2 July 2014 12:31, Darren Etheridge wrote:
> On 07/01/2014 06:39 PM, Guido Martínez wrote:
>>
>> On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote:
>>>
>>> [snip]
>>>
>>> Otherwise I think this is a good and useful patch series.
>>
>> It that a Tested-by tag? :)
>
>
> Sure - I wo
Commit id 2bd16e3e23d9df41592c6b257c59b6860a9cc3ea
(spi: omap2-mcspi: Do not configure the controller
on each transfer unless needed) does its job too
well so omap2_mcspi_setup_transfer() isn't called
even when an SPI slave driver changes 'spi->mode'.
The result is that the mode requested by the SP
Hi,
On Fri, Jun 13, 2014 at 07:11:58PM +, Paul Walmsley wrote:
> Hi Felipe, Tomi,
>
> On Fri, 13 Jun 2014, Felipe Balbi wrote:
>
> > On Fri, Jun 13, 2014 at 11:15:46AM -0500, Felipe Balbi wrote:
> > > From: Sathya Prakash M R
> > >
> > > Add DSS hwmod data for AM43xx.
> > >
> > > Cc: Andr
On Tue, 1 Jul 2014, Will Deacon wrote:
> Hi Mans,
>
> On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote:
> > Russell King - ARM Linux writes:
> > > As you point out, "bx lr" /may/ be treated specially (I've actually been
> >
> > Most, if not all, Cortex-A cores do this according the
On 07/01/2014 06:39 PM, Guido Martínez wrote:
On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote:
[snip]
Otherwise I think this is a good and useful patch series.
It that a Tested-by tag? :)
Sure - I would prefer that the WARN_ON was silenced when the tilcdc
module is removed,
Hi Dave,
did you take a look at this patchset? I foolishly missed adding you on
the To: header, so apologies for that in advance.
Thanks,
On Tue, Jun 17, 2014 at 11:17:02AM -0300, Guido Martínez wrote:
> The tilcdc driver could be compiled as a module, but was severely broken
> and could not be
Hi Pekon,
On Tue, Jul 01, 2014 at 07:01:03AM +, Gupta, Pekon wrote:
> >http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
> >
> I don't think we need above patch.
> Helper macro "for_each_available_child_of_node" internally takes care
> of skipping nodes with status="d
On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote:
> [snip]
>
> Otherwise I think this is a good and useful patch series.
It that a Tested-by tag? :)
Thanks!
Guido
>
> Darren
>
> >The first 7 patches are bug fixes which and should probably be applied
> >in the stable trees. The
Hey Tony and Russel ,
There is a FIX ME message in this function of the file stated in my
subject line.
I was wondering what locking is needed here due to not having experience with
omap subsystem(s).
Cheers Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body
Russell King writes:
> ARMv6 and greater introduced a new instruction ("bx") which can be used
> to return from function calls. Recent CPUs perform better when the
> "bx lr" instruction is used rather than the "mov pc, lr" instruction,
> and this sequence is strongly recommended to be used by th
On Tue, Jul 01, 2014 at 02:40:17PM -0700, Mike Turquette wrote:
> Let's get consensus on my above question before we solidify the API.
> It's worth noting that the current behavior of rounding the rate within
> clk_set_rate is actually what Russell had in mind back in 2010. See this
> thread[1] for
Quoting Paul Walmsley (2014-06-13 12:53:06)
> Furthermore, as a general interface principle, allowing clk_set_rate() to
> silently round rates could lead to unexpected behavior, since the set of
> rates that clk_set_rate() can round to may change between the call to
> clk_round_rate() and the ca
Hi,
On Tue, Jul 01, 2014 at 04:00:20PM -0500, Darren Etheridge wrote:
> Add the necessary nodes to enable the LCD controller and the
> LCD panel that is attached to the Texas Instruments AM335x
> EVMSK platform. Also setup the necessary pin mux within the
> DT file to drive the LCD connector and
Add the necessary nodes to enable the LCD controller and the
LCD panel that is attached to the Texas Instruments AM335x
EVMSK platform. Also setup the necessary pin mux within the
DT file to drive the LCD connector and add the correct
pinmux settings for the lcd pins to be configured to when
the S
Will Deacon writes:
> Hi Mans,
>
> On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>> > As you point out, "bx lr" /may/ be treated specially (I've actually been
>>
>> Most, if not all, Cortex-A cores do this according the public TRMs.
>> They a
Hi,
On Thu, Jun 19, 2014 at 02:33:14PM +0300, Tero Kristo wrote:
> On 06/17/2014 11:04 AM, Tomi Valkeinen wrote:
> >When setting the rate of a clock, by default the clock framework will
> >change the parent of the clock to the most suitable one in
> >__clk_mux_determine_rate() (most suitable by lo
On Tue, Jun 17, 2014 at 08:19:35AM -0500, Felipe Balbi wrote:
> On Tue, Jun 17, 2014 at 04:04:51PM +0530, Sekhar Nori wrote:
> > ROM code on AM437x does not support writing to L2C-310 power control
> > register. The L2C driver, however, tries writing to this register for
> > all revisions >= r3p0.
On 07/01/2014 10:19 AM, Russell King wrote:
> ARMv6 and greater introduced a new instruction ("bx") which can be used
> to return from function calls. Recent CPUs perform better when the
> "bx lr" instruction is used rather than the "mov pc, lr" instruction,
> and this sequence is strongly recomme
Hi Mans,
On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote:
> Russell King - ARM Linux writes:
> > As you point out, "bx lr" /may/ be treated specially (I've actually been
>
> Most, if not all, Cortex-A cores do this according the public TRMs.
> They also do the same thing for "mov p
Russell King - ARM Linux writes:
> On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote:
>> Russell King writes:
>>
>> > ARMv6 and greater introduced a new instruction ("bx") which can be used
>> > to return from function calls. Recent CPUs perform better when the
>> > "bx lr" instruc
On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote:
> Russell King writes:
>
> > ARMv6 and greater introduced a new instruction ("bx") which can be used
> > to return from function calls. Recent CPUs perform better when the
> > "bx lr" instruction is used rather than the "mov pc, lr"
Russell King writes:
> ARMv6 and greater introduced a new instruction ("bx") which can be used
> to return from function calls. Recent CPUs perform better when the
> "bx lr" instruction is used rather than the "mov pc, lr" instruction,
> and this sequence is strongly recommended to be used by th
--- a/arch/arm/mm/proc-arm926.S
+++ b/arch/arm/mm/proc-arm926.S
@@ -55,7 +55,7 @@
* cpu_arm926_proc_init()
*/
ENTRY(cpu_arm926_proc_init)
- mov pc, lr
+ ret lr
/*
* cpu_arm926_proc_fin()
@@ -65,7 +65,7 @@ ENTRY(cpu_arm926_proc_fin)
bic r0, r0, #0x1000
Sekhar Nori wrote at Tuesday, July 01, 2014 3:52 AM:
> Nick,
>
> I have been using your for-next branch to base my development of
> touchscreen support on TI's DRA7x EVM. With the recent updates,
> it has worked out great and once I got the configuration right,
> it was just a question of adding D
On Tue, Jul 1, 2014 at 10:37 AM, Ezequiel García
wrote:
> On 1 July 2014 12:07, Yegor Yefremov wrote:
> [..]
>>
>> What can be done with these error messages:
>>
>> of_get_named_gpiod_flags: can't parse gpios property of node
>> '/ocp/usb@4740/usb-phy@47401300[0]'
>> 47401300.usb-phy supply v
On 1 July 2014 12:07, Yegor Yefremov wrote:
[..]
>
> What can be done with these error messages:
>
> of_get_named_gpiod_flags: can't parse gpios property of node
> '/ocp/usb@4740/usb-phy@47401300[0]'
> 47401300.usb-phy supply vcc not found, using dummy regulator
> musb-hdrc musb-hdrc.0.auto: F
On Tue, Jul 1, 2014 at 3:03 PM, Yegor Yefremov
wrote:
> I have following system:
>
> USB0: host mode (USB hub is soldered internally)
> USB1: OTG mode with OTG connector
>
> My DTS: http://pastebin.com/KB3iTehQ
>
> If I enable DMA in the kernel, I get USB0 working, i.e. USB hub is
> detected and U
* Gupta, Pekon [140701 02:09]:
> >From: Tony Lindgren [mailto:t...@atomide.com]
> >>* Gupta, Pekon [140627 14:08]:
> >> >From: Guido Martínez [mailto:gu...@vanguardiasur.com.ar]
> >> >>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
> >>
> >> [...]
> >>
> >> >> +&gpmc {
> >> >> +
* Roger Quadros [140701 03:13]:
> On 06/13/2014 03:08 PM, Tony Lindgren wrote:
> > * Roger Quadros [140613 04:43]:
> >>
> >> OK. I agree about using some kind of abstraction instead of direct access.
> >
> > Yes and like we chatted on irc, adding a syscon mapping for for
> > the NAND specific re
I have following system:
USB0: host mode (USB hub is soldered internally)
USB1: OTG mode with OTG connector
My DTS: http://pastebin.com/KB3iTehQ
If I enable DMA in the kernel, I get USB0 working, i.e. USB hub is
detected and USB devices, that are connected to this hub are also
detected and worki
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna wrote:
> HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC
> device families as well. The IPs are identical to that of
> OMAP4/OMAP5, except for the number of locks.
>
> Add a depends on to the above family of SoCs to enable the
> buil
* Felipe Balbi [140630 09:47]:
> Hi,
>
> On Mon, Jun 23, 2014 at 01:20:57PM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > here's v3 of am437x sk support. Patches tested on top of next-20140617.
> >
> > Note that this series was tested with the following extra patches:
> >
> > http://marc.info/?l=
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna wrote:
> The number of hwspinlocks are determined based on the value read
> from the IP block's SYSSTATUS register. However, the module may
> not be enabled and clocked, and the read may result in a bus error.
>
> This particular issue is seen
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna wrote:
> static int omap_hwspinlock_probe(struct platform_device *pdev)
> {
> - struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
> + struct device_node *node = pdev->dev.of_node;
> struct hwspinlock_device *bank;
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna wrote:
> 2. The of_hwspin_lock_simple_xlate() is a simple default
>translator function for hwspinlock provider implementations
>that use a single cell number for requesting a specific lock
>(relatively indexed) within a hwlock bank.
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna wrote:
>
> The hwspinlock_device structure is used for registering a bank of
> locks with the driver core. The structure already contains the
> necessary members to identify the bank of locks. The core does not
> maintain the hwspinlock_devices
On Tue, Jul 01, 2014 at 03:06:36PM +0530, Sricharan R wrote:
> Hi Tony,
>
> On Tuesday 01 July 2014 01:29 PM, Tony Lindgren wrote:
> > * Jason Cooper [140630 12:30]:
> >>
> >> Whole series applied to irqchip/crossbar, I'll give it a day or two in
> >> -next, then I'll merge it into irqchip/core.
On Tuesday 01 July 2014 03:55 PM, Roger Quadros wrote:
> On 07/01/2014 01:20 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 01 July 2014 03:43 PM, Roger Quadros wrote:
>>> On 07/01/2014 12:56 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Monday 30 June 2014 04:30 PM, Ro
Hi
You are right. I used a different bootloader for the newer kernels, because of
another build system and did not think about it. The u-boot from
github/gumstix
sets the memory timings different than the u-boot directly from denx.de.
I switched to the gumstix-uboot and i can now allocate all
On 07/01/2014 01:20 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Tuesday 01 July 2014 03:43 PM, Roger Quadros wrote:
>> On 07/01/2014 12:56 PM, Kishon Vijay Abraham I wrote:
>>> Hi Roger,
>>>
>>> On Monday 30 June 2014 04:30 PM, Roger Quadros wrote:
On some SoCs e.g. J6 the 3.3V supply to t
Hi,
On Tuesday 01 July 2014 03:43 PM, Roger Quadros wrote:
> On 07/01/2014 12:56 PM, Kishon Vijay Abraham I wrote:
>> Hi Roger,
>>
>> On Monday 30 June 2014 04:30 PM, Roger Quadros wrote:
>>> On some SoCs e.g. J6 the 3.3V supply to the USB2 PHY can be
>>> powered down when the PHY is not in use. A
On 07/01/2014 12:56 PM, Kishon Vijay Abraham I wrote:
> Hi Roger,
>
> On Monday 30 June 2014 04:30 PM, Roger Quadros wrote:
>> On some SoCs e.g. J6 the 3.3V supply to the USB2 PHY can be
>> powered down when the PHY is not in use. Add regulator
>> management code to control this power line.
>>
>>
+Mark, Alexander, Ivan
Hi Tony,
On 06/13/2014 03:08 PM, Tony Lindgren wrote:
> * Roger Quadros [140613 04:43]:
>> On 06/13/2014 01:46 PM, Tony Lindgren wrote:
>>> * Roger Quadros [140613 01:24]:
On 06/13/2014 11:13 AM, Gupta, Pekon wrote:
>> From: Tony Lindgren [mailto:t...@atomide.com
Hi Roger,
On Monday 30 June 2014 04:30 PM, Roger Quadros wrote:
> On some SoCs e.g. J6 the 3.3V supply to the USB2 PHY can be
> powered down when the PHY is not in use. Add regulator
> management code to control this power line.
>
> Signed-off-by: Roger Quadros
> ---
> drivers/phy/phy-omap-usb2
Nick,
I have been using your for-next branch to base my development of
touchscreen support on TI's DRA7x EVM. With the recent updates,
it has worked out great and once I got the configuration right,
it was just a question of adding DT data for the platform.
Now, there is one problem with Stephen
Hi Tony,
On Tuesday 01 July 2014 01:29 PM, Tony Lindgren wrote:
> * Jason Cooper [140630 12:30]:
>>
>> Whole series applied to irqchip/crossbar, I'll give it a day or two in
>> -next, then I'll merge it into irqchip/core.
>>
>> Tony: Right now, it's immutable unless you tell me I applied somethin
>From: Tony Lindgren [mailto:t...@atomide.com]
>>* Gupta, Pekon [140627 14:08]:
>> >From: Guido Martínez [mailto:gu...@vanguardiasur.com.ar]
>> >>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
>>
>> [...]
>>
>> >> +&gpmc {
>> >> + ranges = <0 0 0 0x0100>;/* address range = 16
* Gupta, Pekon [140627 14:08]:
> >From: Guido Martínez [mailto:gu...@vanguardiasur.com.ar]
> >>On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
>
> [...]
>
> >> +&gpmc {
> >> + ranges = <0 0 0 0x0100>;/* address range = 16MB (minimum GPMC
> >> partition) */
> >> + nand@0,0
* Jason Cooper [140630 12:30]:
>
> Whole series applied to irqchip/crossbar, I'll give it a day or two in
> -next, then I'll merge it into irqchip/core.
>
> Tony: Right now, it's immutable unless you tell me I applied something
> incorrectly. Once it goes into irqchip/core, it's immutable no ma
* Michael Trimarchi [140630 06:49]:
>
> On Mon, Jun 30, 2014 at 3:43 PM, Casper Lyngesen Mogensen
> wrote:
> >
> > I got two new Overo AirStorm today, and they have same behavior. I tried
> > disabling
> > the SMSC9xxx again and booted from MMC. This seems to make the backtrace a
> > little mor
On Mon, 30 Jun 2014, Nishanth Menon wrote:
> reg_info is a generic term which might cause conflict at a later point
> in time. To prevent such a thing from occuring in future, rename to
> palmas_reg_info.
>
> Signed-off-by: Nishanth Menon
> ---
> drivers/regulator/palmas-regulator.c |4 ++--
Hi Guido,
>From: Guido Martínez
>>On Thu, Jun 26, 2014 at 03:40:44AM -0700, Tony Lindgren wrote:
>> * Pekon Gupta [140624 05:26]:
>> > +
>> > +&gpmc {
>> > + ranges = <0 0 0 0x0100>;/* address range = 16MB (minimum GPMC
>> > partition) */
>> > + nand@0,0 {
>> > + status = "dis
58 matches
Mail list logo
