* RE: [PATCH v2 04/28] ARM: mm: cache-l2x0: Add support forre-enabling l2x0
From: Santosh Shilimkar @ 2011-02-05 10:41 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Colin Cross, Will Deacon, Catalin Marinas, Linus Walleij, konkers,
Tony Lindgren, linux-kernel, linux-tegra, olof, linux-arm-kernel
In-Reply-To: <20110205094730.GA23965@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Saturday, February 05, 2011 3:18 PM
> To: Santosh Shilimkar
> Cc: Colin Cross; Will Deacon; Catalin Marinas; Linus Walleij;
> konkers@android.com; Tony Lindgren; linux-kernel@vger.kernel.org;
> linux-tegra@vger.kernel.org; olof@lixom.net; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v2 04/28] ARM: mm: cache-l2x0: Add support
> forre-enabling l2x0
>
> On Sat, Feb 05, 2011 at 01:21:24PM +0530, Santosh Shilimkar wrote:
> > GIC save/restore on OMAP follows different strategy. There is a
> > Predefined layout to save content and restore is done atomically
> > by boot ROM code.
> > L2 cache also same case. Only AUXCTRL needs to be programmed on
> > wakeup from low power mode and that too with secure call. Rest
> > of the registers are managed by boot ROM code.
> >
> > TWD is already managed through framework. Othe CPU low power
> > sequence is very small and OMAP has restrictions on the last
> > core to go down and first to wakeup.
> >
> > So at least I don't see any use of common notifiers for GIC
> > and L2 will help OMAP lower power code.
>
> What this means is that we're going to end up littering things like
> GIC
> and other stuff with lots of individual SoC specific code to save
> state
> into individual SoC specific structures. This is not sane, and
> we're
> not going to corrupt generic code with SoC specific code.
Fully agree and hence flagged it early.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH v2 04/28] ARM: mm: cache-l2x0: Add support for re-enabling l2x0
From: Russell King - ARM Linux @ 2011-02-05 9:47 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Colin Cross, Will Deacon, Catalin Marinas, Linus Walleij,
konkers-z5hGa2qSFaRBDgjK7y7TUQ, Tony Lindgren,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, olof-nZhT3qVonbNeoWH0uzbU5w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1bebe4b5c8590059b70a146d5486fa6a-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sat, Feb 05, 2011 at 01:21:24PM +0530, Santosh Shilimkar wrote:
> GIC save/restore on OMAP follows different strategy. There is a
> Predefined layout to save content and restore is done atomically
> by boot ROM code.
> L2 cache also same case. Only AUXCTRL needs to be programmed on
> wakeup from low power mode and that too with secure call. Rest
> of the registers are managed by boot ROM code.
>
> TWD is already managed through framework. Othe CPU low power
> sequence is very small and OMAP has restrictions on the last
> core to go down and first to wakeup.
>
> So at least I don't see any use of common notifiers for GIC
> and L2 will help OMAP lower power code.
What this means is that we're going to end up littering things like GIC
and other stuff with lots of individual SoC specific code to save state
into individual SoC specific structures. This is not sane, and we're
not going to corrupt generic code with SoC specific code.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v2 04/28] ARM: mm: cache-l2x0: Add support for re-enabling l2x0
From: Santosh Shilimkar @ 2011-02-05 7:51 UTC (permalink / raw)
To: Colin Cross, Russell King - ARM Linux
Cc: Will Deacon, Catalin Marinas, Linus Walleij,
konkers-z5hGa2qSFaRBDgjK7y7TUQ, Tony Lindgren,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, olof-nZhT3qVonbNeoWH0uzbU5w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <AANLkTi=fHnivHXHnYrQvdP6JWbEA3t1X3DuBxj5gN3H0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> -----Original Message-----
> From: ccross-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org [mailto:ccross-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org] On Behalf Of
> Colin Cross
> Sent: Saturday, February 05, 2011 7:15 AM
> To: Russell King - ARM Linux
> Cc: Will Deacon; Santosh Shilimkar; Catalin Marinas; Linus Walleij;
> konkers-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org; Tony Lindgren; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Subject: Re: [PATCH v2 04/28] ARM: mm: cache-l2x0: Add support for
> re-enabling l2x0
>
> On Fri, Feb 4, 2011 at 5:43 PM, Russell King - ARM Linux
> <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> > On Fri, Feb 04, 2011 at 05:32:26PM -0600, Colin Cross wrote:
> >> On Tue, Jan 25, 2011 at 12:39 PM, Will Deacon
> <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> >> > Well if you set the priority fields in the notifier blocks
> correctly
> >> > then you can just return NOTIFY_STOP when you've saved/restored
> as much
> >> > as you want. This assumes of course that you can identify which
> power
> >> > mode you're entering/leaving and that each one is `deeper' than
> the previous.
> >>
> >> I doubt its possible to create an order that will work for all
> >> architectures, and returning NOTIFY_STOP would require the
> decision on
> >> when to finish to be made by the notifier block instead of the
> >> platform code.
> >>
> >> Tegra has three possible idle modes:
> >>
> >> 1. WFI - nothing reset
> >> 2. CPU, TWD, L1, GIC lost, L2 needs to be disabled but not reset
> >> 3. CPU, TWD, L1, GIC, and L2 lost
> >
> > (2) and (3) don't sound like per-cpu modes but system modes. If
> you're
> > having to disable L2, then your other CPU can't be active.
>
> Yes, 2 and 3 require both CPUs to be idle. Unfortunately, on Tegra,
> it is important to use at least 2 as much as possible, because the
> two
> CPUs are not individually power gated.
>
> >> CPU and L1 are already handled by the platform-specific suspend
> code.
> >> TWD is handled by the clockevents broadcast notifiers. That
> leaves L2
> >> and GIC.
> >
> > GIC can be handled in just the same way - upon a CPU idling and it
> > being decided that the CPU should enter low power mode, the idle
> states
> > are entered which does what's required with TWD, L1, VFP, Neon,
> etc.
> > We just need the GIC CPU interface included in there.
> >
> > When both CPUs are idled, then the L2 comes into play, and then
> modes
> > (2) and (3) become possible and this is where you start doing the
> extra
> > stuff.
>
> Are you suggesting that the idle notifiers only handle TWD, L1, VFP,
> Neon, and GIC? That would simplify things, as there are probably no
> ordering requirements, and they should be the same for any platform
> that uses them.
>
> > Note that you have to do it that way anyway, because you can't
> save
> > the state of the other CPU's GIC without doing an IPI call, which
> > could kick it out of its idle mode.
>
> There is currently no state that needs to be saved in the GIC CPU
> registers, they can all be reinitialized.
GIC save/restore on OMAP follows different strategy. There is a
Predefined layout to save content and restore is done atomically
by boot ROM code.
L2 cache also same case. Only AUXCTRL needs to be programmed on
wakeup from low power mode and that too with secure call. Rest
of the registers are managed by boot ROM code.
TWD is already managed through framework. Othe CPU low power
sequence is very small and OMAP has restrictions on the last
core to go down and first to wakeup.
So at least I don't see any use of common notifiers for GIC
and L2 will help OMAP lower power code.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 04/28] ARM: mm: cache-l2x0: Add support for re-enabling l2x0
From: Colin Cross @ 2011-02-05 1:44 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Will Deacon, Santosh Shilimkar, Catalin Marinas, Linus Walleij,
konkers-z5hGa2qSFaRBDgjK7y7TUQ, Tony Lindgren,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, olof-nZhT3qVonbNeoWH0uzbU5w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20110204234331.GF8732-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
On Fri, Feb 4, 2011 at 5:43 PM, Russell King - ARM Linux
<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> On Fri, Feb 04, 2011 at 05:32:26PM -0600, Colin Cross wrote:
>> On Tue, Jan 25, 2011 at 12:39 PM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
>> > Well if you set the priority fields in the notifier blocks correctly
>> > then you can just return NOTIFY_STOP when you've saved/restored as much
>> > as you want. This assumes of course that you can identify which power
>> > mode you're entering/leaving and that each one is `deeper' than the previous.
>>
>> I doubt its possible to create an order that will work for all
>> architectures, and returning NOTIFY_STOP would require the decision on
>> when to finish to be made by the notifier block instead of the
>> platform code.
>>
>> Tegra has three possible idle modes:
>>
>> 1. WFI - nothing reset
>> 2. CPU, TWD, L1, GIC lost, L2 needs to be disabled but not reset
>> 3. CPU, TWD, L1, GIC, and L2 lost
>
> (2) and (3) don't sound like per-cpu modes but system modes. If you're
> having to disable L2, then your other CPU can't be active.
Yes, 2 and 3 require both CPUs to be idle. Unfortunately, on Tegra,
it is important to use at least 2 as much as possible, because the two
CPUs are not individually power gated.
>> CPU and L1 are already handled by the platform-specific suspend code.
>> TWD is handled by the clockevents broadcast notifiers. That leaves L2
>> and GIC.
>
> GIC can be handled in just the same way - upon a CPU idling and it
> being decided that the CPU should enter low power mode, the idle states
> are entered which does what's required with TWD, L1, VFP, Neon, etc.
> We just need the GIC CPU interface included in there.
>
> When both CPUs are idled, then the L2 comes into play, and then modes
> (2) and (3) become possible and this is where you start doing the extra
> stuff.
Are you suggesting that the idle notifiers only handle TWD, L1, VFP,
Neon, and GIC? That would simplify things, as there are probably no
ordering requirements, and they should be the same for any platform
that uses them.
> Note that you have to do it that way anyway, because you can't save
> the state of the other CPU's GIC without doing an IPI call, which
> could kick it out of its idle mode.
There is currently no state that needs to be saved in the GIC CPU
registers, they can all be reinitialized.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 04/28] ARM: mm: cache-l2x0: Add support for re-enabling l2x0
From: Russell King - ARM Linux @ 2011-02-04 23:43 UTC (permalink / raw)
To: Colin Cross
Cc: Will Deacon, Santosh Shilimkar, Catalin Marinas, Linus Walleij,
konkers, Tony Lindgren, linux-kernel, linux-tegra, olof,
linux-arm-kernel
In-Reply-To: <AANLkTi=cTXmQFm_s5OL2pGyyaFv5UR_f9MV=S5Ajx0tu@mail.gmail.com>
On Fri, Feb 04, 2011 at 05:32:26PM -0600, Colin Cross wrote:
> On Tue, Jan 25, 2011 at 12:39 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Well if you set the priority fields in the notifier blocks correctly
> > then you can just return NOTIFY_STOP when you've saved/restored as much
> > as you want. This assumes of course that you can identify which power
> > mode you're entering/leaving and that each one is `deeper' than the previous.
>
> I doubt its possible to create an order that will work for all
> architectures, and returning NOTIFY_STOP would require the decision on
> when to finish to be made by the notifier block instead of the
> platform code.
>
> Tegra has three possible idle modes:
>
> 1. WFI - nothing reset
> 2. CPU, TWD, L1, GIC lost, L2 needs to be disabled but not reset
> 3. CPU, TWD, L1, GIC, and L2 lost
(2) and (3) don't sound like per-cpu modes but system modes. If you're
having to disable L2, then your other CPU can't be active.
> CPU and L1 are already handled by the platform-specific suspend code.
> TWD is handled by the clockevents broadcast notifiers. That leaves L2
> and GIC.
GIC can be handled in just the same way - upon a CPU idling and it
being decided that the CPU should enter low power mode, the idle states
are entered which does what's required with TWD, L1, VFP, Neon, etc.
We just need the GIC CPU interface included in there.
When both CPUs are idled, then the L2 comes into play, and then modes
(2) and (3) become possible and this is where you start doing the extra
stuff.
Note that you have to do it that way anyway, because you can't save
the state of the other CPU's GIC without doing an IPI call, which
could kick it out of its idle mode.
^ permalink raw reply
* Re: [PATCH v2 04/28] ARM: mm: cache-l2x0: Add support for re-enabling l2x0
From: Colin Cross @ 2011-02-04 23:32 UTC (permalink / raw)
To: Will Deacon
Cc: Santosh Shilimkar, Catalin Marinas, Russell King - ARM Linux,
Linus Walleij, konkers-z5hGa2qSFaRBDgjK7y7TUQ, Tony Lindgren,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, olof-nZhT3qVonbNeoWH0uzbU5w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <-8932138696981683633@unknownmsgid>
On Tue, Jan 25, 2011 at 12:39 PM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> Santosh,
>
>> > > Maybe we need a notifier list which can be told when cpuidle
>> > events
>> > > happen, so that parts of the system such as VFP and L2 cache
>> > support
>> > > can do the right thing without having platforms add lots of stuff
>> > like
>> > >
>> > > gic_secondary_init();
>> > > gic_restore_interrupt_types();
>> > > vfp_enable();
>> > > l2x0_enable();
>> > > twd_enable();
>> > > ... etc ...
>> > >
>> > > in their SoC specific code.
>> >
>> > But do we need a strict order between such operations? The notifier
>> > call
>> > chain isn't too flexible.
>> >
>> I guess it does depends on how the archs have integrated a9. Example
>> on OMAP there are different power modes possible.
>> 1. CPU context ,TWD lost
>> 2. CPU context ,TWD + L1 is lost
>> 3. CPU context + L1 is lost + GIC lost
>> 4. CPU context + L1 is lost + GIC lost + L2 lost
>> So there is need to have flexibility of calling these function
>> based on power modes. I don't know how notifiers can give
>> this flexibility
>
> Well if you set the priority fields in the notifier blocks correctly
> then you can just return NOTIFY_STOP when you've saved/restored as much
> as you want. This assumes of course that you can identify which power
> mode you're entering/leaving and that each one is `deeper' than the previous.
I doubt its possible to create an order that will work for all
architectures, and returning NOTIFY_STOP would require the decision on
when to finish to be made by the notifier block instead of the
platform code.
Tegra has three possible idle modes:
1. WFI - nothing reset
2. CPU, TWD, L1, GIC lost, L2 needs to be disabled but not reset
3. CPU, TWD, L1, GIC, and L2 lost
CPU and L1 are already handled by the platform-specific suspend code.
TWD is handled by the clockevents broadcast notifiers. That leaves L2
and GIC.
The L2 can be idled in two ways: just disable it, but keep the
contents, which prevents having to refill the cache, or a full reset.
Disabling can already be handled by outer_cache_disable().
The GIC needs to be idled differently depending on which cpus are
idle. On Tegra, if both cpus are idle, the secondary cpu needs to
disable its GIC and go to WFI, while the first cpu saves the GIC
distributor state and powers off both cpus.
While it seems possible to handle all of these cases with a notifier
chain, the amount of platform-specific knowledge and ordering seems
too much to make it worthwhile.
If the ordering requirements are close enough between platforms, or
non-existent (I don't think there are any requirements on Tegra), a
notifier chain with a mask of the hardware that is being reset could
work. On Tegra, in case 2 above, CPU1 would call:
idle_notify(IDLE_ENTER | GIC_DISABLE)
and CPU0 would call:
idle_notify(IDLE_ENTER | GIC_DISABLE | GIC_SAVE | L2_DISABLE)
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] USB: ehci: tegra: Align DMA transfers to 32 bytes
From: Greg KH @ 2011-02-04 20:35 UTC (permalink / raw)
To: rmorell-DDmLM1+adcrQT0dZR+AlfA
Cc: Olof Johansson, Greg KH, David Brownell, Benoit Goby, Alan Stern,
Sarah Sharp, Matthew Wilcox, Ming Lei, Jacob Pan, Oliver Neukum,
Erik Gilling, Colin Cross,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20110204202640.GC1744-f3YH7lVHJt/FT5IIyIEb6QC/G2K4zDHf@public.gmane.org>
On Fri, Feb 04, 2011 at 12:26:40PM -0800, rmorell-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org wrote:
> On Fri, Feb 04, 2011 at 12:16:16PM -0800, Greg KH wrote:
> > On Fri, Feb 04, 2011 at 12:14:54PM -0800, Olof Johansson wrote:
> > > On Fri, Feb 4, 2011 at 11:49 AM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> wrote:
> > > > This file doesn't seem to be in any tree that I can find, including my
> > > > own, so I can't apply this patch.
> > > >
> > > > What am I supposed to do with it?
> > >
> > > It hasn't been posted for upstream yet, so nothing for you to do. The
> > > driver will be posted for review soon, hopefully in time for .39.
> >
> > Then why would someone send me a patch for it already?
>
> Sorry, this is my fault. My immediate need is to get this merged into
> our release linux-tegra-2.6.36 branch, but wanted to get broad review
> for the change since it affects USB core code. I figured that it will
> be easier to push the full driver into the USB tree with this part out
> of the way already, anyway.
Ok, that makes more sense, but next time, please say something,
as I wasted a lot of time trying to figure out why this patch wasn't
applying correctly :(
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 1/6] ASoC: Tegra: Harmony: Add headphone jack detection
From: Stephen Warren @ 2011-02-04 20:32 UTC (permalink / raw)
To: Mark Brown
Cc: lrg-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF0310C8EA93-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
Stephen Warren wrote at Thursday, February 03, 2011 4:25 PM:
>
> Mark Brown wrote at Thursday, February 03, 2011 3:36 PM:
> > On Thu, Feb 03, 2011 at 01:56:13PM -0700, Stephen Warren wrote:
> >
> > > +static struct snd_soc_jack harmony_hp_jack;
> > > +
> >
> > Since you've changed to using a platform device you should really be
> > dynamically allocating this I guess. But this isn't actually a
> > practical problem so not worth caring about.
>
> Uggh. The code may as well be consistent. I'll fix this up and resubmit
> if you haven't already applied it.
Hmm. Looking at this a bit more, solving it fully is kinda nasty; I'd have
to move not only that jack definition, but also all the pins and gpios into
struct tegra_harmony, since snd_soc_jack_add_{pins,gpios} modify all of
those structures. But, there would still have to be static const "template"
copies of those data structures to initialize the copies in struct
tegra_harmony.
The same thing then applies to some of the subsequent changes, for the
mic jacks etc.
That seems like a lot of overhead, both code-wise, and runtime space-wise,
to solve a problem that as you mention isn't a practical concern.
--
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] USB: ehci: tegra: Align DMA transfers to 32 bytes
From: rmorell-DDmLM1+adcrQT0dZR+AlfA @ 2011-02-04 20:26 UTC (permalink / raw)
To: Greg KH
Cc: Olof Johansson, Greg KH, David Brownell, Benoit Goby, Alan Stern,
Sarah Sharp, Matthew Wilcox, Ming Lei, Jacob Pan, Oliver Neukum,
Erik Gilling, Colin Cross,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20110204201616.GA12482-l3A5Bk7waGM@public.gmane.org>
On Fri, Feb 04, 2011 at 12:16:16PM -0800, Greg KH wrote:
> On Fri, Feb 04, 2011 at 12:14:54PM -0800, Olof Johansson wrote:
> > On Fri, Feb 4, 2011 at 11:49 AM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> wrote:
> > > This file doesn't seem to be in any tree that I can find, including my
> > > own, so I can't apply this patch.
> > >
> > > What am I supposed to do with it?
> >
> > It hasn't been posted for upstream yet, so nothing for you to do. The
> > driver will be posted for review soon, hopefully in time for .39.
>
> Then why would someone send me a patch for it already?
Sorry, this is my fault. My immediate need is to get this merged into
our release linux-tegra-2.6.36 branch, but wanted to get broad review
for the change since it affects USB core code. I figured that it will
be easier to push the full driver into the USB tree with this part out
of the way already, anyway.
Thanks,
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] USB: ehci: tegra: Align DMA transfers to 32 bytes
From: Greg KH @ 2011-02-04 20:16 UTC (permalink / raw)
To: Olof Johansson
Cc: Greg KH, Robert Morell, David Brownell, Benoit Goby, Alan Stern,
Sarah Sharp, Matthew Wilcox, Ming Lei, Jacob Pan, Oliver Neukum,
Erik Gilling, Colin Cross, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTinRtch4Pvr3GLz5wZU2xkG3FMJxxzSNAdParA7j-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Feb 04, 2011 at 12:14:54PM -0800, Olof Johansson wrote:
> On Fri, Feb 4, 2011 at 11:49 AM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> wrote:
> > On Wed, Jan 26, 2011 at 07:06:49PM -0800, Robert Morell wrote:
> >> The Tegra2 USB controller doesn't properly deal with misaligned DMA
> >> buffers, causing corruption. This is especially prevalent with USB
> >> network adapters, where skbuff alignment is often in the middle of a
> >> 4-byte dword.
> >>
> >> To avoid this, allocate a temporary buffer for the DMA if the provided
> >> buffer isn't sufficiently aligned.
> >>
> >> Signed-off-by: Robert Morell <rmorell-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >> ---
> >> drivers/usb/host/ehci-tegra.c | 90 +++++++++++++++++++++++++++++++++++++++++
> >
> > This file doesn't seem to be in any tree that I can find, including my
> > own, so I can't apply this patch.
> >
> > What am I supposed to do with it?
>
> It hasn't been posted for upstream yet, so nothing for you to do. The
> driver will be posted for review soon, hopefully in time for .39.
Then why would someone send me a patch for it already?
Still confused,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] USB: ehci: tegra: Align DMA transfers to 32 bytes
From: Olof Johansson @ 2011-02-04 20:14 UTC (permalink / raw)
To: Greg KH
Cc: Robert Morell, David Brownell, Greg Kroah-Hartman, Benoit Goby,
Alan Stern, Sarah Sharp, Matthew Wilcox, Ming Lei, Jacob Pan,
Oliver Neukum, Erik Gilling, Colin Cross,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110204194954.GA25180-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Fri, Feb 4, 2011 at 11:49 AM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Jan 26, 2011 at 07:06:49PM -0800, Robert Morell wrote:
>> The Tegra2 USB controller doesn't properly deal with misaligned DMA
>> buffers, causing corruption. This is especially prevalent with USB
>> network adapters, where skbuff alignment is often in the middle of a
>> 4-byte dword.
>>
>> To avoid this, allocate a temporary buffer for the DMA if the provided
>> buffer isn't sufficiently aligned.
>>
>> Signed-off-by: Robert Morell <rmorell-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> ---
>> drivers/usb/host/ehci-tegra.c | 90 +++++++++++++++++++++++++++++++++++++++++
>
> This file doesn't seem to be in any tree that I can find, including my
> own, so I can't apply this patch.
>
> What am I supposed to do with it?
It hasn't been posted for upstream yet, so nothing for you to do. The
driver will be posted for review soon, hopefully in time for .39.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] USB: ehci: tegra: Align DMA transfers to 32 bytes
From: Greg KH @ 2011-02-04 19:49 UTC (permalink / raw)
To: Robert Morell
Cc: David Brownell, Greg Kroah-Hartman, Benoit Goby, Alan Stern,
Sarah Sharp, Matthew Wilcox, Ming Lei, Jacob Pan, Oliver Neukum,
Olof Johansson, Erik Gilling, Colin Cross, linux-usb,
linux-kernel, linux-tegra
In-Reply-To: <1296097609-32302-4-git-send-email-rmorell@nvidia.com>
On Wed, Jan 26, 2011 at 07:06:49PM -0800, Robert Morell wrote:
> The Tegra2 USB controller doesn't properly deal with misaligned DMA
> buffers, causing corruption. This is especially prevalent with USB
> network adapters, where skbuff alignment is often in the middle of a
> 4-byte dword.
>
> To avoid this, allocate a temporary buffer for the DMA if the provided
> buffer isn't sufficiently aligned.
>
> Signed-off-by: Robert Morell <rmorell@nvidia.com>
> ---
> drivers/usb/host/ehci-tegra.c | 90 +++++++++++++++++++++++++++++++++++++++++
This file doesn't seem to be in any tree that I can find, including my
own, so I can't apply this patch.
What am I supposed to do with it?
confused,
greg k-h
^ permalink raw reply
* RE: [PATCH 6/6] ASoC: Tegra: Harmony: Support both int and ext mics
From: Stephen Warren @ 2011-02-04 17:20 UTC (permalink / raw)
To: Mark Brown
Cc: lrg-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20110203225235.GD4586-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Mark Brown wrote at Thursday, February 03, 2011 3:53 PM:
> On Thu, Feb 03, 2011 at 01:56:18PM -0700, Stephen Warren wrote:
>
> > At present, I'm not sure how best to resolve this. Downstream drivers
> > directly tweaked the wm8903's registers so that both ADCs processed the
> > same input channel.
>
> The CODEC driver needs to have support for routing the left and right
> channels like things like the WM8993 do.
>
> > {"IN1L", NULL, "Mic Jack"},
> > + {"IN1R", NULL, "Mic Jack"},
>
> This looks odd - I'd expect to see separate widgets for the internal
> microphone rather than using the same widget.
Yes, separate widgets would make sense.
However, I wonder how this interacts with mic detection using micbias current.
There is only one mic bias signal, routed to a subset of the mics using the
two per-mic enable GPIOs. Should I just hook up the mic bias detection to
both jacks somehow, or is the only option to just punt on jack detection?
There are no physical plug detection mechanisms on this board.
> This would greatly simplify the driver code without really impacting the
> level of configuration applications need to do (and allowing them to use
> both simultaneously if they want to).
I guess you could, although even with L/R routing implemented for the
single-mic case, I think the only option for dual-mic would be to capture
each mic on its own channel, which seems like an unlikely use case to me.
But who knows, maybe it could be useful for e.g. noise-cancelling in SW?
--
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/6] ASoC: Tegra: Harmony: Add headphone jack detection
From: Mark Brown @ 2011-02-04 14:47 UTC (permalink / raw)
To: Stephen Warren
Cc: linux-tegra@vger.kernel.org, alsa-devel@alsa-project.org,
lrg@slimlogic.co.uk
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF0310C8EA93@HQMAIL01.nvidia.com>
On Thu, Feb 03, 2011 at 03:25:04PM -0800, Stephen Warren wrote:
> Uggh. The code may as well be consistent. I'll fix this up and resubmit
> if you haven't already applied it.
Except when he's on holiday or otherwise unavailable I won't generally
apply anything unless it's an emergency bugfix until Liam has also
reviewed it.
^ permalink raw reply
* Re: [PATCH 5/6] ASoC: Harmony: Call snd_soc_dapm_nc_pin
From: Mark Brown @ 2011-02-04 14:46 UTC (permalink / raw)
To: Stephen Warren
Cc: lrg-kDsPt+C1G03kYMGBc/C6ZA, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1296766578-13988-5-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Thu, Feb 03, 2011 at 01:56:17PM -0700, Stephen Warren wrote:
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Similarly here.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/6] ASoC: Tegra: Harmony: Add switch control for speaker
From: Mark Brown @ 2011-02-04 14:46 UTC (permalink / raw)
To: Stephen Warren
Cc: lrg-kDsPt+C1G03kYMGBc/C6ZA, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1296766578-13988-2-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Thu, Feb 03, 2011 at 01:56:14PM -0700, Stephen Warren wrote:
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
This looks good but won't apply without patch 1 so please resubmit.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 1/6] ASoC: Tegra: Harmony: Add headphone jack detection
From: Stephen Warren @ 2011-02-03 23:25 UTC (permalink / raw)
To: Mark Brown
Cc: lrg-kDsPt+C1G03kYMGBc/C6ZA@public.gmane.org,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20110203223530.GA4586-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Mark Brown wrote at Thursday, February 03, 2011 3:36 PM:
> On Thu, Feb 03, 2011 at 01:56:13PM -0700, Stephen Warren wrote:
>
> > +static struct snd_soc_jack harmony_hp_jack;
> > +
>
> Since you've changed to using a platform device you should really be
> dynamically allocating this I guess. But this isn't actually a
> practical problem so not worth caring about.
Uggh. The code may as well be consistent. I'll fix this up and resubmit
if you haven't already applied it.
--
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/6] ASoC: Tegra: Harmony: Support both int and ext mics
From: Mark Brown @ 2011-02-03 22:52 UTC (permalink / raw)
To: Stephen Warren; +Cc: linux-tegra, alsa-devel, lrg
In-Reply-To: <1296766578-13988-6-git-send-email-swarren@nvidia.com>
On Thu, Feb 03, 2011 at 01:56:18PM -0700, Stephen Warren wrote:
> At present, I'm not sure how best to resolve this. Downstream drivers
> directly tweaked the wm8903's registers so that both ADCs processed the
> same input channel.
The CODEC driver needs to have support for routing the left and right
channels like things like the WM8993 do.
> {"IN1L", NULL, "Mic Jack"},
> + {"IN1R", NULL, "Mic Jack"},
This looks odd - I'd expect to see separate widgets for the internal
microphone rather than using the same widget. This would greatly
simplify the driver code without really impacting the level of
configuration applications need to do (and allowing them to use both
simultaneously if they want to).
> +static int harmony_set_mic_selection(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
> + struct snd_soc_card *card = codec->card;
> + struct tegra_harmony *harmony = snd_soc_card_get_drvdata(card);
> +
> + if (harmony->mic_selection == ucontrol->value.integer.value[0])
> + return 0;
> +
> + harmony->mic_selection = ucontrol->value.integer.value[0];
> + harmony_mic_control(codec);
This should be locking the CODEC mutex while doing the update.
> +static const struct soc_enum harmony_enum[] = {
> + SOC_ENUM_SINGLE_EXT(ARRAY_SIZE(mic_selection_names),
> + mic_selection_names),
> };
Don't create arrays of enums, declare individual varaibles and reference
them...
> + SOC_ENUM_EXT("Mic Selection", harmony_enum[0],
> + harmony_get_mic_selection, harmony_set_mic_selection),
...as it makes the references to them much easier to follow and less
error prone.
^ permalink raw reply
* Re: [PATCH 4/6] ASoC: Tegra: Harmony: Implement mic detection
From: Mark Brown @ 2011-02-03 22:40 UTC (permalink / raw)
To: Stephen Warren
Cc: lrg-kDsPt+C1G03kYMGBc/C6ZA, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1296766578-13988-4-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Thu, Feb 03, 2011 at 01:56:16PM -0700, Stephen Warren wrote:
> * Remove Mic Bias from DAPM route map, so that Mic Bias isn't disable
> when capture is stopped, thus preventing further mic detection from
> operating.
You should be using snd_soc_dapm_force_enable_pin() to do this.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/6] ASoC: WM8903: Fix mic detection issues
From: Mark Brown @ 2011-02-03 22:38 UTC (permalink / raw)
To: Stephen Warren
Cc: lrg-kDsPt+C1G03kYMGBc/C6ZA, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1296766578-13988-3-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Thu, Feb 03, 2011 at 01:56:15PM -0700, Stephen Warren wrote:
> wm8903.h:
> * There is no hysteresis enable field in the current datasheet.
> * Mic detection threshold field is only 2 bits wide.
>
> wm8903.c:
> * Mic detection HW should be enabled if SW wants either mic detection or
> short detection, rather than only when it wants both.
Please don't combine unrelated changes into a single patch, especially
in cases like this where one is a bug fix and the other is essentially a
cosmetic fixup.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/6] ASoC: Tegra: Harmony: Add headphone jack detection
From: Mark Brown @ 2011-02-03 22:35 UTC (permalink / raw)
To: Stephen Warren
Cc: lrg-kDsPt+C1G03kYMGBc/C6ZA, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1296766578-13988-1-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Thu, Feb 03, 2011 at 01:56:13PM -0700, Stephen Warren wrote:
> +static struct snd_soc_jack harmony_hp_jack;
> +
Since you've changed to using a platform device you should really be
dynamically allocating this I guess. But this isn't actually a
practical problem so not worth caring about.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox