Hi Tomi,
thanks for cleaning up the commit messages and reposting these so quickly.
On Tue, 23 Aug 2011, Tomi Valkeinen wrote:
> These are the previously sent HWMOD patches split into smaller pieces and with
> improved commit messages.
>
> I'm not sure if these are strictly needed to be sent fo
Hi,
On Sun, Aug 28, 2011 at 4:11 AM, Alan Stern wrote:
> On Sun, 28 Aug 2011, Ming Lei wrote:
>
>> Looks like there is still another similar problem in qh_link_async():
>> the last wmb
>> should be changed into mb, because HC will read 'head->hw->hw_next' from qh
>> descriptor and this pointer in
Hi,
Thanks for your comment.
On Sun, Aug 28, 2011 at 4:06 AM, Alan Stern wrote:
> On Sun, 28 Aug 2011, Ming Lei wrote:
>
>> I read the doc again, :-), and it mentions few about mb/wmb/rmb, I think
>> my above description is still not correct. Generally speaking, mb only
>> means there is a order
Beloved,I am Deborah Mannings.I write this email to you on my sick bed
facing death.I have a substantial sum I would like you to help me
distribute to the needy and helpless.God bless you as you reply through
mann_...@yahoo.cn
--
To unsubscribe from this list: send the line "unsubscribe linux-omap
On Fri, 26 Aug 2011, David Gibson wrote:
> static struct of_device_id foodevice_of_match[] __devinitdata = {
> { .compatible = "foocorp,foodevice1234",
> .resource_names = {"base_regs", "extra_regs", }, },
> { .compatible = "foocorp,foodevice1239",
> .resource_names = {
On Sun, 28 Aug 2011, Ming Lei wrote:
> Looks like there is still another similar problem in qh_link_async():
> the last wmb
> should be changed into mb, because HC will read 'head->hw->hw_next' from qh
> descriptor and this pointer in qh is read only for HC. But this problem can't
> be
> observed
On Sun, 28 Aug 2011, Ming Lei wrote:
> I read the doc again, :-), and it mentions few about mb/wmb/rmb, I think
> my above description is still not correct. Generally speaking, mb only
> means there is a order between two accesses.
>
> Now I think only one mb() after 'dummy->hw_token = token;' is
On Fri, 26 Aug 2011, Arnd Bergmann wrote:
> I don't think anyone was talking about converting driver /to/ the
> _byname method
For drivers that use multiple resources of the same type, converting those
to use platform_get_resource_byname() does indeed seem appropriate.
By the way, the same IP b
On Sat, 27 Aug 2011, Santosh wrote:
> On Saturday 27 August 2011 07:31 PM, Alan Stern wrote:
> > On Sat, 27 Aug 2011, Santosh wrote:
> >
> >> I might be wrong here, but after discussion with Govindraj on this
> >> issue, it seems there is a flaw in the way OMAP chain handler
> >> handling the chil
On Sat, 27 Aug 2011, Arnd Bergmann wrote:
> Right, and I guess we can simply ignore DMA and ioport resources because
> they are extremely rare, right?
DMA resources are quite widely used.
For example, looking at the SoCs with some publicly-available
documentation, the Motorola i.MX51 reference
On Sunday 28 August 2011 00:37:36 David Gibson wrote:
> On Fri, Aug 26, 2011 at 05:41:29PM +0200, Arnd Bergmann wrote:
> > On Friday 26 August 2011, Arnd Bergmann wrote:
> > > On Friday 26 August 2011, David Gibson wrote:
> > > > If you open code it this way then yes, it's silly. But what about
>
Hi,
On Sun, Aug 28, 2011 at 12:57 AM, Ming Lei wrote:
>> Are you sure? Have you read the documentation about memory barriers to
>> confirm this?
>
> I read the doc again, :-), and it mentions few about mb/wmb/rmb, I think
> my above description is still not correct. Generally speaking, mb only
Hi,
Thanks for your comment.
On Sun, Aug 28, 2011 at 12:07 AM, Greg KH wrote:
>> As Santosh pointed out, mb on ARM will flush L2 write buffer. The
>> description here is wrong.
>
> Then this can't be accepted as-is :)
Yes, I will update it in v1, :-)
>> I think the below should make the writi
On Fri, Aug 26, 2011 at 9:46 PM, Guenter Roeck
wrote:
> On Fri, 2011-08-26 at 07:17 -0400, J, KEERTHY wrote:
>> On Thu, Aug 25, 2011 at 9:26 PM, Guenter Roeck
>> wrote:
>> > On Thu, 2011-08-25 at 10:06 -0400, Guenter Roeck wrote:
>> >> On Thu, Aug 25, 2011 at 06:30:07AM -0400, J, KEERTHY wrote:
>
Hello.
On 27-08-2011 18:48, ming@canonical.com wrote:
From: Ming Lei
This patch fixs one performance bug on ARM Cortex A9 dual core platform,
which has been reported on quite a few ARM machines(OMAP4, Tegra 2,
snowball...),
see details from link of https://bugs.launchpad.net/bugs/709245
On Sat, Aug 27, 2011 at 11:33:26PM +0800, Ming Lei wrote:
> Hi,
>
> On Sat, Aug 27, 2011 at 11:13 PM, Greg KH wrote:
> > On Sat, Aug 27, 2011 at 10:48:35PM +0800, ming@canonical.com wrote:
> >> From: Ming Lei
> >>
> >> This patch fixs one performance bug on ARM Cortex A9 dual core platform,
On Saturday 27 August 2011 08:48 PM, Ming Lei wrote:
On Sat, Aug 27, 2011 at 11:03 PM, Santosh wrote:
Hi,
On Saturday 27 August 2011 08:18 PM, ming@canonical.com wrote:
From: Ming Lei
This patch fixs one performance bug on ARM Cortex A9 dual core platform,
which has been reported on qui
On Fri, Aug 26, 2011 at 05:41:29PM +0200, Arnd Bergmann wrote:
> On Friday 26 August 2011, Arnd Bergmann wrote:
> > On Friday 26 August 2011, David Gibson wrote:
> > > If you open code it this way then yes, it's silly. But what about
> > > something like this:
> > >
> > > static struct of_device_
Hi,
On Sat, Aug 27, 2011 at 11:13 PM, Greg KH wrote:
> On Sat, Aug 27, 2011 at 10:48:35PM +0800, ming@canonical.com wrote:
>> From: Ming Lei
>>
>> This patch fixs one performance bug on ARM Cortex A9 dual core platform,
>> which has been reported on quite a few ARM machines(OMAP4, Tegra 2,
On Sat, Aug 27, 2011 at 11:03 PM, Santosh wrote:
> Hi,
>
> On Saturday 27 August 2011 08:18 PM, ming@canonical.com wrote:
>>
>> From: Ming Lei
>>
>> This patch fixs one performance bug on ARM Cortex A9 dual core platform,
>> which has been reported on quite a few ARM machines(OMAP4, Tegra 2,
>
On Sat, Aug 27, 2011 at 10:48:35PM +0800, ming@canonical.com wrote:
> From: Ming Lei
>
> This patch fixs one performance bug on ARM Cortex A9 dual core platform,
> which has been reported on quite a few ARM machines(OMAP4, Tegra 2,
> snowball...),
> see details from link of https://bugs.laun
Hi,
On Saturday 27 August 2011 08:18 PM, ming@canonical.com wrote:
From: Ming Lei
This patch fixs one performance bug on ARM Cortex A9 dual core platform,
which has been reported on quite a few ARM machines(OMAP4, Tegra 2,
snowball...),
see details from link of https://bugs.launchpad.net/b
On Saturday 27 August 2011 07:31 PM, Alan Stern wrote:
On Sat, 27 Aug 2011, Santosh wrote:
I might be wrong here, but after discussion with Govindraj on this
issue, it seems there is a flaw in the way OMAP chain handler
handling the child interrupts.
On OMAP, we have special interrupt wakeup s
From: Ming Lei
This patch fixs one performance bug on ARM Cortex A9 dual core platform,
which has been reported on quite a few ARM machines(OMAP4, Tegra 2,
snowball...),
see details from link of https://bugs.launchpad.net/bugs/709245.
In fact, one mb() on ARM is enough to flush L2 cache, but
'd
From: Ming Lei
This patch fixs one performance bug on ARM Cortex A9 dual core platform,
which has been reported on quite a few ARM machines(OMAP4, Tegra 2,
snowball...),
see details from link of https://bugs.launchpad.net/bugs/709245.
In fact, one mb() on ARM is enough to flush L2 cache, but
'd
On Sat, 27 Aug 2011, Santosh wrote:
> I might be wrong here, but after discussion with Govindraj on this
> issue, it seems there is a flaw in the way OMAP chain handler
> handling the child interrupts.
>
> On OMAP, we have special interrupt wakeup source at PRCM level and
> many devices can trigg
The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf and mmap
prevent
requesting a larger size buffer than what is allocated at kernel boot during
omap_vout_probe.
The requested size is comapred with vout->buffer_size, this isn't correct as
vout->buffer_size is later set to the size r
On Mon, Aug 22, 2011 at 4:27 PM, Tomi Valkeinen wrote:
> Currently omapfb wants that all the display devices have a driver,
> otherwise omapfb refuses to start. There's no real requirement to act
> like that, and this patch will make omapfb give a warning and skip that
> device.
Hi Tomi,
Just a
> -Original Message-
> From: Kevin Hilman [mailto:khil...@ti.com]
> Sent: Saturday, August 27, 2011 4:55 AM
> To: Menon, Nishanth
> Cc: Tero Kristo; linux-omap@vger.kernel.org; Vishwanath Sripathy
> Subject: Re: [RFC 1/2] OMAP3+: voltage / oscillator parameter
> segregation
>
> Hi Nishanth,
29 matches
Mail list logo
