* [alsa-devel] [PATCH 1/3] pxa: Enable pxa-pcm-audio on pxa210/pxa25x platform
From: Liam Girdwood @ 2011-02-23 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298417351-24727-1-git-send-email-dbaryshkov@gmail.com>
On Wed, 2011-02-23 at 02:29 +0300, Dmitry Eremin-Solenikov wrote:
> pxa25x platforms were left out of major ASoC Update patch.
> Since f0fba2ad1b a registration of pxa-pcm-audio device is required for
> ASoC to function on pxa platforms. Register one also for pxa210/pxa25x.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> ---
> arch/arm/mach-pxa/pxa25x.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
> index fbc5b77..b166b1d 100644
> --- a/arch/arm/mach-pxa/pxa25x.c
> +++ b/arch/arm/mach-pxa/pxa25x.c
> @@ -347,6 +347,7 @@ static struct platform_device *pxa25x_devices[] __initdata = {
> &pxa25x_device_assp,
> &pxa25x_device_pwm0,
> &pxa25x_device_pwm1,
> + &pxa_device_asoc_platform,
> };
>
> static struct sys_device pxa25x_sysdev[] = {
All
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
^ permalink raw reply
* [PATCH v4 6/7] arm/dt: Basic tegra devicetree support
From: Sergei Shtylyov @ 2011-02-23 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110223022234.18318.90592.stgit@localhost6.localdomain6>
Hello.
On 23-02-2011 5:22, Grant Likely wrote:
> This patch adds adds very basic support for booting tegra with a
> device tree. It simply allows the existing machine_descs to match
> against the tegra compatible values so that the kernel can boot.
> Kernel parameters and the initrd pointer is read out of the tree
> instead of atags.
> This is not complete device tree support. This change will be
> reverted when a new machine_desc is added that can populate the
> device registrations directly from data in the tree instead of using
> hard coded data. That change will be made in a future patch.
> v2: Fixed cut-and-paste error in commit text
Shouldn't this sentence follow the --- tearline?
> Signed-off-by: Grant Likely<grant.likely@secretlab.ca>
WBR, Sergei
^ permalink raw reply
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Colin Cross @ 2011-02-23 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimffVNK2EmTqypQcrWHLisf3c8_dMsHwSbv-nWi@mail.gmail.com>
On Wed, Feb 23, 2011 at 1:08 PM, Olof Johansson <olof@lixom.net> wrote:
> Stephen,
>
> Since this depends on i2c, and registers one of the adapters to do it,
> we should just get the adapters registered separately (all of them)
> before this. I was holding off that part of board code since the i2c
> driver went up that maintainer path instead, but if Colin pulls it
> into tegra for-next, then I'll go ahead with those peices as well.
>
> I'll pick up the board-side patches from this series (1, 4, 5), and
> Colin will take the core patches (2, 3).
>
>
> On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
>
>> +static struct wm8903_platform_data harmony_wm8903_pdata = {
>> + ? ? ? .irq_active_low = 0,
>> + ? ? ? .micdet_cfg = 0,
>> + ? ? ? .micdet_delay = 100,
>> + ? ? ? .gpio_base = GPIO_WM8903(0),
>> + ? ? ? .gpio_cfg = {
>> + ? ? ? ? ? ? ? WM8903_GPIO_NO_CONFIG,
>> + ? ? ? ? ? ? ? WM8903_GPIO_NO_CONFIG,
>> + ? ? ? ? ? ? ? 0,
>> + ? ? ? ? ? ? ? WM8903_GPIO_NO_CONFIG,
>> + ? ? ? ? ? ? ? WM8903_GPIO_NO_CONFIG,
>> + ? ? ? },
>> +};
> [...]
>> diff --git a/arch/arm/mach-tegra/board-harmony.h b/arch/arm/mach-tegra/board-harmony.h
>> index 4fe33b8..fbf2304 100644
>> --- a/arch/arm/mach-tegra/board-harmony.h
>> +++ b/arch/arm/mach-tegra/board-harmony.h
>> @@ -17,12 +17,19 @@
>> ?#ifndef _MACH_TEGRA_BOARD_HARMONY_H
>> ?#define _MACH_TEGRA_BOARD_HARMONY_H
>>
>> +#define GPIO_WM8903(_x_) ? ? ? ? ? ? ? (TEGRA_NR_GPIOS + (_x_))
>
>
> The above assumes that wm8903 is the GPIO controller that gets
> allocated the numbers right after native tegra gpio. That might not be
> the case on all boards, since the TPS PMIC has some as well, I
> believe.
The GPIO numbers above TEGRA_NR_GPIOS are allocated by the board, and
this is in board-harmony.h, so I think its OK.
> Does it need a hardcoded GPIO base, or can it use the dynamic one
> (i.e. use -1 here)? I don't even see any reference to gpio_base in the
> driver...
I assume that is in the ASoC tree. The platform data in tegra
for-next does not include a gpio_base entry.
^ permalink raw reply
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Stephen Warren @ 2011-02-23 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=Nxh8YKBSDhVVAW4Sqzd6yKj=D6X=R+9KT+UBK@mail.gmail.com>
Colin Cross wrote at Wednesday, February 23, 2011 2:08 PM:
>
> On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
> > * Set up platform data required by I2C, and ASoC machine & codec drivers.
> > * Enable required GPIO pins as GPIOs.
> > * Initialize audio-related clocks.
> > * Correctly configure pinmux for audio-related GPIOs.
> >
> > Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > diff --git a/arch/arm/mach-tegra/board-harmony.h b/arch/arm/mach-tegra/board-harmony.h
> > ...
> > +#define GPIO_WM8903(_x_) ? ? ? ? ? ? ? (TEGRA_NR_GPIOS + (_x_))
> Can you name this HARMONY_GPIO_WM8903?
Sure. But then, wouldn't it make sense to also rename all the TEGRA_GPIO_*
below too?
> > +
> > ?#define TEGRA_GPIO_SD2_CD ? ? ? ? ? ? ?TEGRA_GPIO_PI5
> > ?#define TEGRA_GPIO_SD2_WP ? ? ? ? ? ? ?TEGRA_GPIO_PH1
> > ?#define TEGRA_GPIO_SD2_POWER ? ? ? ? ? TEGRA_GPIO_PT3
> > ?#define TEGRA_GPIO_SD4_CD ? ? ? ? ? ? ?TEGRA_GPIO_PH2
> > ?#define TEGRA_GPIO_SD4_WP ? ? ? ? ? ? ?TEGRA_GPIO_PH3
> > ?#define TEGRA_GPIO_SD4_POWER ? ? ? ? ? TEGRA_GPIO_PI6
> > +#define TEGRA_GPIO_CDC_IRQ ? ? ? ? ? ? TEGRA_GPIO_PX3
> > +#define TEGRA_GPIO_SPKR_EN ? ? ? ? ? ? GPIO_WM8903(2)
> > +#define TEGRA_GPIO_HP_DET ? ? ? ? ? ? ?TEGRA_GPIO_PW2
> > +#define TEGRA_GPIO_INT_MIC_EN ? ? ? ? ?TEGRA_GPIO_PX0
> > +#define TEGRA_GPIO_EXT_MIC_EN ? ? ? ? ?TEGRA_GPIO_PX1
--
nvpublic
^ permalink raw reply
* [GIT PULL] Please pull tegra board updates for .39
From: Olof Johansson @ 2011-02-23 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimA1=CCXM8wmkoatL59mzitC=5-GK3HUs-_daE9@mail.gmail.com>
Colin,
Since things got held up due to rebases and a few patch respins,
here's a fresh pull request and diff stats. Please pull
boards-for-next.
Given current activity, I expect to stage one more pull before the
merge window once the i2c driver is in the main tegra for-next branch.
The following changes since commit 38376866a1fe5b1e6d9510ec4913c2b461f456f3:
Mark Brown (1):
ARM: tegra: Hide EMC scaling config behind ARCH_TEGRA
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra-2.6.git
boards-for-next
Olof Johansson (7):
ARM: tegra: add tegra_gpio_table and tegra_gpio_config
ARM: tegra: harmony: move over to tegra_gpio_config
ARM: tegra: common device resources
ARM: tegra: remove stale nvidia atag handler
ARM: tegra: harmony: register sdhci devices
ARM: tegra: harmony: fix pinmux for MMC slot
ARM: tegra: add seaboard, wario and kaen boards
arch/arm/mach-tegra/Kconfig | 19 +
arch/arm/mach-tegra/Makefile | 4 +
arch/arm/mach-tegra/board-harmony-pinmux.c | 19 +-
arch/arm/mach-tegra/board-harmony.c | 55 ++--
arch/arm/mach-tegra/board-seaboard-pinmux.c | 179 ++++++++++
arch/arm/mach-tegra/board-seaboard.c | 196 +++++++++++
arch/arm/mach-tegra/board-seaboard.h | 38 ++
arch/arm/mach-tegra/devices.c | 505 +++++++++++++++++++++++++++
arch/arm/mach-tegra/devices.h | 46 +++
arch/arm/mach-tegra/gpio.c | 14 +
arch/arm/mach-tegra/include/mach/gpio.h | 7 +
11 files changed, 1054 insertions(+), 28 deletions(-)
create mode 100644 arch/arm/mach-tegra/board-seaboard-pinmux.c
create mode 100644 arch/arm/mach-tegra/board-seaboard.c
create mode 100644 arch/arm/mach-tegra/board-seaboard.h
create mode 100644 arch/arm/mach-tegra/devices.c
create mode 100644 arch/arm/mach-tegra/devices.h
^ permalink raw reply
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Colin Cross @ 2011-02-23 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF03112A5D7D@HQMAIL01.nvidia.com>
On Wed, Feb 23, 2011 at 1:16 PM, Stephen Warren <swarren@nvidia.com> wrote:
> Colin Cross wrote at Wednesday, February 23, 2011 2:08 PM:
>>
>> On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
>> > * Set up platform data required by I2C, and ASoC machine & codec drivers.
>> > * Enable required GPIO pins as GPIOs.
>> > * Initialize audio-related clocks.
>> > * Correctly configure pinmux for audio-related GPIOs.
>> >
>> > Signed-off-by: Stephen Warren <swarren@nvidia.com>
>> > diff --git a/arch/arm/mach-tegra/board-harmony.h b/arch/arm/mach-tegra/board-harmony.h
>> > ...
>> > +#define GPIO_WM8903(_x_) ? ? ? ? ? ? ? (TEGRA_NR_GPIOS + (_x_))
>> Can you name this HARMONY_GPIO_WM8903?
>
> Sure. But then, wouldn't it make sense to also rename all the TEGRA_GPIO_*
> below too?
True, but no point in adding churn. Those can be cleaned up later. I
just want it to be clear that the numbering of gpios above
TEGRA_NR_GPIOS is specific to the board, so the next board author
doesn't get it wrong.
>> > +
>> > ?#define TEGRA_GPIO_SD2_CD ? ? ? ? ? ? ?TEGRA_GPIO_PI5
>> > ?#define TEGRA_GPIO_SD2_WP ? ? ? ? ? ? ?TEGRA_GPIO_PH1
>> > ?#define TEGRA_GPIO_SD2_POWER ? ? ? ? ? TEGRA_GPIO_PT3
>> > ?#define TEGRA_GPIO_SD4_CD ? ? ? ? ? ? ?TEGRA_GPIO_PH2
>> > ?#define TEGRA_GPIO_SD4_WP ? ? ? ? ? ? ?TEGRA_GPIO_PH3
>> > ?#define TEGRA_GPIO_SD4_POWER ? ? ? ? ? TEGRA_GPIO_PI6
>> > +#define TEGRA_GPIO_CDC_IRQ ? ? ? ? ? ? TEGRA_GPIO_PX3
>> > +#define TEGRA_GPIO_SPKR_EN ? ? ? ? ? ? GPIO_WM8903(2)
>> > +#define TEGRA_GPIO_HP_DET ? ? ? ? ? ? ?TEGRA_GPIO_PW2
>> > +#define TEGRA_GPIO_INT_MIC_EN ? ? ? ? ?TEGRA_GPIO_PX0
>> > +#define TEGRA_GPIO_EXT_MIC_EN ? ? ? ? ?TEGRA_GPIO_PX1
>
> --
> nvpublic
>
>
^ permalink raw reply
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Colin Cross @ 2011-02-23 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimffVNK2EmTqypQcrWHLisf3c8_dMsHwSbv-nWi@mail.gmail.com>
On Wed, Feb 23, 2011 at 1:08 PM, Olof Johansson <olof@lixom.net> wrote:
> Stephen,
>
> Since this depends on i2c, and registers one of the adapters to do it,
> we should just get the adapters registered separately (all of them)
> before this. I was holding off that part of board code since the i2c
> driver went up that maintainer path instead, but if Colin pulls it
> into tegra for-next, then I'll go ahead with those peices as well.
I'll merge the i2c-tegra branch into for-next (assuming Ben doesn't
object to it), and you can put all the i2c devices in your pull
request. That way we can get everything except this patch into the
first pull request to Linus, and just put this patch into a second
pull request once the ASoC branch is merged.
^ permalink raw reply
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Olof Johansson @ 2011-02-23 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikk6f0Nv8XZEmY4-85FtBE1re9hKqgFRNZkyPfz@mail.gmail.com>
Hi,
> The GPIO numbers above TEGRA_NR_GPIOS are allocated by the board, and
> this is in board-harmony.h, so I think its OK.
On second thought, it's probably even preferred, since otherwise the
dynamic allocation can mess up the static ones.
>> Does it need a hardcoded GPIO base, or can it use the dynamic one
>> (i.e. use -1 here)? I don't even see any reference to gpio_base in the
>> driver...
> I assume that is in the ASoC tree. ?The platform data in tegra
> for-next does not include a gpio_base entry.
Yeah, I only looked at the current driver in .37, my bad.
-Olof
^ permalink raw reply
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Stephen Warren @ 2011-02-23 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikk6f0Nv8XZEmY4-85FtBE1re9hKqgFRNZkyPfz@mail.gmail.com>
Colin Cross wrote at Wednesday, February 23, 2011 2:16 PM:
>
> On Wed, Feb 23, 2011 at 1:08 PM, Olof Johansson <olof@lixom.net> wrote:
> > ...
> > On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
> > [...]
> >> diff --git a/arch/arm/mach-tegra/board-harmony.h b/arch/arm/mach-tegra/board-harmony.h
> >> index 4fe33b8..fbf2304 100644
> >> --- a/arch/arm/mach-tegra/board-harmony.h
> >> +++ b/arch/arm/mach-tegra/board-harmony.h
> >> @@ -17,12 +17,19 @@
> >> ?#ifndef _MACH_TEGRA_BOARD_HARMONY_H
> >> ?#define _MACH_TEGRA_BOARD_HARMONY_H
> >>
> >> +#define GPIO_WM8903(_x_) ? ? ? ? ? ? ? (TEGRA_NR_GPIOS + (_x_))
> >
> >
> > The above assumes that wm8903 is the GPIO controller that gets
> > allocated the numbers right after native tegra gpio. That might not be
> > the case on all boards, since the TPS PMIC has some as well, I
> > believe.
> The GPIO numbers above TEGRA_NR_GPIOS are allocated by the board, and
> this is in board-harmony.h, so I think its OK.
The Seaboard equivalent of this that I wrote for ChromeOS is:
#define TPS_GPIO_BASE TEGRA_NR_GPIOS
#define TPS_GPIO_WWAN_PWR (TPS_GPIO_BASE + 2)
#define GPIO_WM8903(_x_) (TPS_GPIO_BASE + 4 + (_x_))
Which takes into account other devices.
> > Does it need a hardcoded GPIO base, or can it use the dynamic one
> > (i.e. use -1 here)? I don't even see any reference to gpio_base in the
> > driver...
> I assume that is in the ASoC tree. The platform data in tegra
> for-next does not include a gpio_base entry.
Yes, gpio_base is added to that tree.
-1 would probably work. But then, I have no idea how to find out what base
was assigned to the WM8903, in order to initialize the ASoC machine driver's
platform_data...
--
nvpublic
^ permalink raw reply
* [PATCH v2] ARM: Thumb-2: Reflect ARM/Thumb-2 configuration in module vermagic
From: Sergei Shtylyov @ 2011-02-23 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298462021-22177-1-git-send-email-dave.martin@linaro.org>
Hello.
On 23-02-2011 14:53, Dave Martin wrote:
> Loading Thumb-2 modules into an ARM kernel or vice-versa isn't
> guaranteed to work safely, since the kernel is not interworking-
> aware everywhere.
> This patch adds "thumb2" to the module vermagic when
> CONFIG_THUMB2_KERNEL is enabled, to help avoid accidental loading
> of modules into the wrong kernel.
> v2: modified to apply consistently on top of rmk's p2v branch.
Patch changelog should follow the -- tearline.
> Signed-off-by: Dave Martin<dave.martin@linaro.org>
> Acked-by: Nicolas Pitre<nicolas.pitre@linaro.org>
WBR, Sergei
^ permalink raw reply
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Olof Johansson @ 2011-02-23 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=tDJvfEFFvXGEkZswRWekRLuz4rBoT-0hgobgn@mail.gmail.com>
On Wed, Feb 23, 2011 at 1:21 PM, Colin Cross <ccross@android.com> wrote:
> On Wed, Feb 23, 2011 at 1:08 PM, Olof Johansson <olof@lixom.net> wrote:
>> Stephen,
>>
>> Since this depends on i2c, and registers one of the adapters to do it,
>> we should just get the adapters registered separately (all of them)
>> before this. I was holding off that part of board code since the i2c
>> driver went up that maintainer path instead, but if Colin pulls it
>> into tegra for-next, then I'll go ahead with those peices as well.
>
> I'll merge the i2c-tegra branch into for-next (assuming Ben doesn't
> object to it), and you can put all the i2c devices in your pull
> request. ?That way we can get everything except this patch into the
> first pull request to Linus, and just put this patch into a second
> pull request once the ASoC branch is merged.
Sure, that works. I'll stage the i2c changes tonight.
-Olof
^ permalink raw reply
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Olof Johansson @ 2011-02-23 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF03112A5D88@HQMAIL01.nvidia.com>
On Wed, Feb 23, 2011 at 1:22 PM, Stephen Warren <swarren@nvidia.com> wrote:
> Colin Cross wrote at Wednesday, February 23, 2011 2:16 PM:
>>
>> On Wed, Feb 23, 2011 at 1:08 PM, Olof Johansson <olof@lixom.net> wrote:
>> > ...
>> > On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
>> > [...]
>> >> diff --git a/arch/arm/mach-tegra/board-harmony.h b/arch/arm/mach-tegra/board-harmony.h
>> >> index 4fe33b8..fbf2304 100644
>> >> --- a/arch/arm/mach-tegra/board-harmony.h
>> >> +++ b/arch/arm/mach-tegra/board-harmony.h
>> >> @@ -17,12 +17,19 @@
>> >> ?#ifndef _MACH_TEGRA_BOARD_HARMONY_H
>> >> ?#define _MACH_TEGRA_BOARD_HARMONY_H
>> >>
>> >> +#define GPIO_WM8903(_x_) ? ? ? ? ? ? ? (TEGRA_NR_GPIOS + (_x_))
>> >
>> >
>> > The above assumes that wm8903 is the GPIO controller that gets
>> > allocated the numbers right after native tegra gpio. That might not be
>> > the case on all boards, since the TPS PMIC has some as well, I
>> > believe.
>> The GPIO numbers above TEGRA_NR_GPIOS are allocated by the board, and
>> this is in board-harmony.h, so I think its OK.
>
> The Seaboard equivalent of this that I wrote for ChromeOS is:
>
> #define TPS_GPIO_BASE ? ? ? ? ? ? ? ? ? TEGRA_NR_GPIOS
>
> #define TPS_GPIO_WWAN_PWR ? ? ? ? ? ? ? (TPS_GPIO_BASE + 2)
>
> #define GPIO_WM8903(_x_) ? ? ? ? ? ? ? ?(TPS_GPIO_BASE + 4 + (_x_))
>
> Which takes into account other devices.
>
>> > Does it need a hardcoded GPIO base, or can it use the dynamic one
>> > (i.e. use -1 here)? I don't even see any reference to gpio_base in the
>> > driver...
>> I assume that is in the ASoC tree. ?The platform data in tegra
>> for-next does not include a gpio_base entry.
>
> Yes, gpio_base is added to that tree.
>
> -1 would probably work. But then, I have no idea how to find out what base
> was assigned to the WM8903, in order to initialize the ASoC machine driver's
> platform_data...
Yeah, like I said in a separate reply, keeping it the way it is will
work out for the best.
-Olof
^ permalink raw reply
* [PATCH] MAINTAINERS: Update MSM maintainers
From: Bryan Huntsman @ 2011-02-23 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikuaOL7mdARoNtx2ZJGJm6FBrqizrit6_uSaUte@mail.gmail.com>
On 02/22/2011 05:12 PM, Linus Torvalds wrote:
> On Tue, Feb 22, 2011 at 4:19 PM, Daniel Walker <dwalker@fifo99.com> wrote:
>> On Tue, 2011-02-22 at 16:03 -0800, David Brown wrote:
>>> Remove Bryan Huntsman and Daniel Walker from the MSM maintainer list.
>>>
>>
>> No.. I don't sign off on this.. Please ignore this Linus.
>
> Guys, you need to sort out your differences here..
>
> Linus
Daniel, let's do what Linus is asking and figure this out. What is your
intention here? Going forward, David Brown is in the best position to
handle MSM maintenance since he has direct access to all past, current,
and future MSM devices as well as all the HW and SW experts at Qualcomm.
In that spirit, I think it's entirely appropriate for both you and I to
step back and let David handle this role so that there is one consistent
and clear voice for MSM.
- Bryan
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: Guzman Lugo, Fernando @ 2011-02-23 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D656961.7080105@maxwell.research.nokia.com>
On Wed, Feb 23, 2011 at 2:09 PM, Sakari Ailus
<sakari.ailus@maxwell.research.nokia.com> wrote:
> Guzman Lugo, Fernando wrote:
>> Hi,
>
> Hi Fernando,
>
>> In OMAP4 the cortex M3 is a double core processor and as each core is
>> running they own version of the RTOS we threat them independently. So
>> our driver which controls the remote processor sees two processor but
>> both use the same iommu hw. When a iommu fault happens, at this
>> moment, it is consider as a faltal error and it is no managed to
>> recover and continue, instead a restart of the processor is needed, if
>> the fault happens in core0 we need to reset core1 too and vice versa.
>> if the iommu would support several user callbacks, we can register the
>> callback which resets core0 and also the callback which resets core1
>> and treat them as totally independent processors. Also we have an
>> error event notifier driver, which is only in charge of notifying
>> error events to userspace, so we would have multiple callbacks we
>> could do this
>
> The original purpose of the patch, as far as I understand, is to allow
> getting useful information for debugging purposes should an iommu fault
> happen.
>
> Also, I'm not sure it's necessarily a good idea to just go and reset
> the M3 cores in case an iommu fault happens --- this is very probably a
> grave bug in the software running on those M3s. It should be fixed
> instead of just hiding it. There will be consequences to host side as
> well, won't there?
the code running in the M3 side is a RTOS, and it does not have
something like kernel and userspace as linux, so if some app crashes
it crash the whole system (like a crash in a driver) it can be
improved later. And the issues in the host side are taking into
account, host apps are notified about the issue and they release and
start the communication with the remote cores.
But event if we were able to fixed the issue, think is this example
you have two independent OS running on each core of the cortex M3
(core0 and core1). You make your own mapping in core0 and your own
mapping in core1 and each core has a callback for mmu fault:
case 1: mmufault in core1:
1.- iommu fault isr in iommu module is triggered and it calls to all callbacks.
2.- it calls callback for core0 (cb_c0)
3.- cb_c0 tries to fix the problem but, as it does not have
information about that fault address (core1 does)it can not fixed the
issue and return an error to say it could not manage the issue.
4.- iommu fault isr check the value returned by cb_c0 and it sees
cb_c0 did not fix the issue, so it call to the next callback (cb_c1)
5.- cb_c1 is executed and fixes the issue and they continue working.
case 2: mmufault in core0:
1.- iommu fault isr in iommu module is triggered and it calls to all callbacks.
2.- it calls callback for core0 (cb_c0)
3.- cb_c0 fixes the problem and returns a success value.
4.- iommu fault isr check the value returned by cb_c0 and it sees
cb_c0 it fixed the issue, so it does not call any other callback
(cb_c1)
So, multiple callbacks looks really nice for me.
Regards,
Fernando.
>
>> iommu <---- register fault callback for error notify driver
>>
>> instead of
>>
>> iommu <--- register fault callback for remote processor driver
>> <----register fault event for error notify driver.
>>
>> with that, we remove one dependency of the errornotify driver.
>
> I suppose this is not in mainline?
>
> Regards,
>
> --
> Sakari Ailus
> sakari.ailus at maxwell.research.nokia.com
>
^ permalink raw reply
* [GIT PULL] Please pull tegra board updates for .39
From: Colin Cross @ 2011-02-23 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim99BSkaX-hm8kb43tm6YJY5VUk6OYL6SwyPmD5@mail.gmail.com>
On Wed, Feb 23, 2011 at 1:17 PM, Olof Johansson <olof@lixom.net> wrote:
> Colin,
>
> Since things got held up due to rebases and a few patch respins,
> here's a fresh pull request and diff stats. Please pull
> boards-for-next.
>
> Given current activity, I expect to stage one more pull before the
> merge window once the i2c driver is in the main tegra for-next branch.
>
>
>
> The following changes since commit 38376866a1fe5b1e6d9510ec4913c2b461f456f3:
> ?Mark Brown (1):
> ? ? ? ?ARM: tegra: Hide EMC scaling config behind ARCH_TEGRA
>
> are available in the git repository at:
>
> ?git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra-2.6.git
> boards-for-next
>
> Olof Johansson (7):
> ? ? ?ARM: tegra: add tegra_gpio_table and tegra_gpio_config
> ? ? ?ARM: tegra: harmony: move over to tegra_gpio_config
> ? ? ?ARM: tegra: common device resources
> ? ? ?ARM: tegra: remove stale nvidia atag handler
> ? ? ?ARM: tegra: harmony: register sdhci devices
> ? ? ?ARM: tegra: harmony: fix pinmux for MMC slot
> ? ? ?ARM: tegra: add seaboard, wario and kaen boards
>
> ?arch/arm/mach-tegra/Kconfig ? ? ? ? ? ? ? ? | ? 19 +
> ?arch/arm/mach-tegra/Makefile ? ? ? ? ? ? ? ?| ? ?4 +
> ?arch/arm/mach-tegra/board-harmony-pinmux.c ?| ? 19 +-
> ?arch/arm/mach-tegra/board-harmony.c ? ? ? ? | ? 55 ++--
> ?arch/arm/mach-tegra/board-seaboard-pinmux.c | ?179 ++++++++++
> ?arch/arm/mach-tegra/board-seaboard.c ? ? ? ?| ?196 +++++++++++
> ?arch/arm/mach-tegra/board-seaboard.h ? ? ? ?| ? 38 ++
> ?arch/arm/mach-tegra/devices.c ? ? ? ? ? ? ? | ?505 +++++++++++++++++++++++++++
> ?arch/arm/mach-tegra/devices.h ? ? ? ? ? ? ? | ? 46 +++
> ?arch/arm/mach-tegra/gpio.c ? ? ? ? ? ? ? ? ?| ? 14 +
> ?arch/arm/mach-tegra/include/mach/gpio.h ? ? | ? ?7 +
> ?11 files changed, 1054 insertions(+), 28 deletions(-)
> ?create mode 100644 arch/arm/mach-tegra/board-seaboard-pinmux.c
> ?create mode 100644 arch/arm/mach-tegra/board-seaboard.c
> ?create mode 100644 arch/arm/mach-tegra/board-seaboard.h
> ?create mode 100644 arch/arm/mach-tegra/devices.c
> ?create mode 100644 arch/arm/mach-tegra/devices.h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
Thanks, merged to tegra/for-next
^ permalink raw reply
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Stephen Warren @ 2011-02-23 21:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinzVinbW_rDt5Rqe7i68P2u_XvDvRWA8R2mq0_9@mail.gmail.com>
Olof Johansson wrote at Wednesday, February 23, 2011 2:25 PM:
> On Wed, Feb 23, 2011 at 1:21 PM, Colin Cross <ccross@android.com> wrote:
> > On Wed, Feb 23, 2011 at 1:08 PM, Olof Johansson <olof@lixom.net> wrote:
> >> Stephen,
> >>
> >> Since this depends on i2c, and registers one of the adapters to do it,
> >> we should just get the adapters registered separately (all of them)
> >> before this. I was holding off that part of board code since the i2c
> >> driver went up that maintainer path instead, but if Colin pulls it
> >> into tegra for-next, then I'll go ahead with those peices as well.
> >
> > I'll merge the i2c-tegra branch into for-next (assuming Ben doesn't
> > object to it), and you can put all the i2c devices in your pull
> > request. ?That way we can get everything except this patch into the
> > first pull request to Linus, and just put this patch into a second
> > pull request once the ASoC branch is merged.
>
> Sure, that works. I'll stage the i2c changes tonight.
OK, so just so I'm clear:
Patches 1..4 are all going in as-is.
I should re-post patch 5 once the merge window is open, having rebased
it on Olof's i2c registration changes, and
s/GPIO_WM8903/HARMONY_GPIO_WM8903/. Or, should I repost as soon as Olof
has updated his branch with the I2C changes, and you'll just hold off
applying it until the merge window?
Thanks.
--
nvpublic
^ permalink raw reply
* [PATCH v4 6/7] arm/dt: Basic tegra devicetree support
From: Grant Likely @ 2011-02-23 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D657880.50405@ru.mvista.com>
On Thu, Feb 24, 2011 at 12:13:36AM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 23-02-2011 5:22, Grant Likely wrote:
>
> >This patch adds adds very basic support for booting tegra with a
> >device tree. It simply allows the existing machine_descs to match
> >against the tegra compatible values so that the kernel can boot.
> >Kernel parameters and the initrd pointer is read out of the tree
> >instead of atags.
>
> >This is not complete device tree support. This change will be
> >reverted when a new machine_desc is added that can populate the
> >device registrations directly from data in the tree instead of using
> >hard coded data. That change will be made in a future patch.
>
> >v2: Fixed cut-and-paste error in commit text
>
> Shouldn't this sentence follow the --- tearline?
Nope! It is actually quite useful for the version information to show
up in the commit text. That way you know *exactly* which version got
merged. dwmw2 pointed that out to me a few months back.
^ permalink raw reply
* [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: Guzman Lugo, Fernando @ 2011-02-23 21:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D657490.20504@maxwell.research.nokia.com>
On Wed, Feb 23, 2011 at 2:56 PM, Sakari Ailus
<sakari.ailus@maxwell.research.nokia.com> wrote:
> David Cohen wrote:
>> On Wed, Feb 23, 2011 at 3:39 PM, Guzman Lugo, Fernando
>> <fernando.lugo@ti.com> wrote:
>>> On Wed, Feb 23, 2011 at 3:45 AM, David Cohen <dacohen@gmail.com> wrote:
>>>> On Wed, Feb 23, 2011 at 3:17 AM, Guzman Lugo, Fernando
>>>> <fernando.lugo@ti.com> wrote:
>>>>> On Wed, Feb 16, 2011 at 1:35 PM, David Cohen <dacohen@gmail.com> wrote:
>>>>>> Add support to register an isr for IOMMU fault situations and adapt it
>>>>>> to allow such (*isr)() to be used as fault callback. Drivers using IOMMU
>>>>>> module might want to be informed when errors happen in order to debug it
>>>>>> or react.
>>>>>>
>>>>>> Signed-off-by: David Cohen <dacohen@gmail.com>
>>>>>> ---
>>>>>> ?arch/arm/mach-omap2/iommu2.c ? ? ? ? ? ?| ? 17 +++++++++-
>>>>>> ?arch/arm/plat-omap/include/plat/iommu.h | ? 14 ++++++++-
>>>>>> ?arch/arm/plat-omap/iommu.c ? ? ? ? ? ? ?| ? 52 ++++++++++++++++++++++---------
>>>>>> ?3 files changed, 65 insertions(+), 18 deletions(-)
>>>>>>
>>>>> ....
>>>>>
>>>>>> @@ -917,6 +912,33 @@ void iommu_put(struct iommu *obj)
>>>>>> ?}
>>>>>> ?EXPORT_SYMBOL_GPL(iommu_put);
>>>>>>
>>>>>> +int iommu_set_isr(const char *name,
>>>>>> + ? ? ? ? ? ? ? ? int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs,
>>>>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?void *priv),
>>>>>> + ? ? ? ? ? ? ? ? void *isr_priv)
>>>>>> +{
>>>>>> + ? ? ? struct device *dev;
>>>>>> + ? ? ? struct iommu *obj;
>>>>>> +
>>>>>
>>>>> if the driver support multiple user for the same iommu why can only
>>>>> one callback be registered? should it support register multiple
>>>>> callback function (one per user)?
>>>>
>>>> Can you define a scenario for that?
>>>> On OMAP3 ISP the multiple users are the multiple ISP submodule, but I
>>>> don't think it's necessary all submodule to have a specific callback.
>>>> ISP core layer should handle.
>>>
>>> Hi,
>>>
>>> In OMAP4 the cortex M3 is a double core processor and as each core is
>>> running they own version of the RTOS we threat them independently. So
>>> our driver which controls the remote processor sees two processor but
>>> both use the same iommu hw. When a iommu fault happens, at this
>>> moment, it is consider as a faltal error and it is no managed to
>>> recover and continue, instead a restart of the processor is needed, if
>>> the fault happens in core0 we need to reset core1 too and vice versa.
>>> if the iommu would support several user callbacks, we can register the
>>> callback which resets core0 and also the callback which resets core1
>>> and treat them as totally independent processors. Also we have an
>>> error event notifier driver, which is only in charge of notifying
>>> error events to userspace, so we would have multiple callbacks we
>>> could do this
>>
>> I understood your point. In this case, I may not disagree about having
>> more than one callback per obj, although it doesn't seem a nice
>> scenario.
>> We can have a list of callbacks and call the entire list when a fault
>> happens. But it's necessary to pay attention it will happen in atomic
>> context and users should not abuse and register many callbacks. The
>> callback should *NOT* print useless messages and must verify the error
>> code to not execute useless steps.
>> In this context, callback and ISR cannot share a same pointer anymore.
>
> I think this is outside of the scope of the patch but...
yes, the same behaviour was before the patches, but as the patches are
changing the isr, I think it is a good time to modify, not in patch 2,
but in a new patch to be added to the serie between patch 1 and 2, so
that we dont need to change ISR part again after this set of patches.
>
> To efficiently debug iommu faults (with a driver using iommu page
> walking), besides the actual fault address the list of existing mappings
> and the information which driver created them and for which purpose is
> useful.
>
> The list of mappings is already available in the iommu structure. It'd
> be nice if there was a function a driver could call to print them.
>
> I can only think of ugly ways to implement the other.
>
> Just my 5 cents (as we have no 2 cent coins here).
>
> Regards,
>
> --
> Sakari Ailus
> sakari.ailus at maxwell.research.nokia.com
>
^ permalink raw reply
* [PATCH v3] ARM: Tegra: DMA: Fail safe if initialization fails
From: Stephen Warren @ 2011-02-23 21:49 UTC (permalink / raw)
To: linux-arm-kernel
tegra_dma_init currently simply bails out early if any initialization fails.
This skips various data-structure initialization. In turn, this means that
tegra_dma_allocate_channel can still hand out channels. In this case, when
tegra_dma_free_channel is called, which calls tegra_dma_cancel, the walking
on ch->list will OOPS since the list's next/prev pointers may still be
NULL.
To solve this, add an explicit "initialized" flag, only set this once _init
has fully completed successfully, and have _allocate_channel refuse to hand
out channels if this is not set.
While at it, simplify _init:
* Remove redundant memsets
* Use bitmap_fill to mark all channels as in-use up-front, and remove
some now-redundant bitmap initialization loops.
* Only mark a channel as free once all channel-related initialization has
completed.
Finally, the successful exit path from _init always has ret==0, so just
hard-code that return. The error path still returns ret.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v3:
s/initialized/tegra_dma_initialized/
Change type to bool, assign true not 1
Add WARN_ON
Revert whitespace cleanup
arch/arm/mach-tegra/dma.c | 22 ++++++++++------------
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-tegra/dma.c b/arch/arm/mach-tegra/dma.c
index bd4f62a..e945ae2 100644
--- a/arch/arm/mach-tegra/dma.c
+++ b/arch/arm/mach-tegra/dma.c
@@ -127,6 +127,7 @@ struct tegra_dma_channel {
#define NV_DMA_MAX_CHANNELS 32
+static bool tegra_dma_initialized;
static DEFINE_MUTEX(tegra_dma_lock);
static DECLARE_BITMAP(channel_usage, NV_DMA_MAX_CHANNELS);
@@ -352,6 +353,9 @@ struct tegra_dma_channel *tegra_dma_allocate_channel(int mode)
int channel;
struct tegra_dma_channel *ch = NULL;
+ if (WARN_ON(!tegra_dma_initialized))
+ return NULL;
+
mutex_lock(&tegra_dma_lock);
/* first channel is the shared channel */
@@ -678,6 +682,8 @@ int __init tegra_dma_init(void)
void __iomem *addr;
struct clk *c;
+ bitmap_fill(channel_usage, NV_DMA_MAX_CHANNELS);
+
c = clk_get_sys("tegra-dma", NULL);
if (IS_ERR(c)) {
pr_err("Unable to get clock for APB DMA\n");
@@ -696,18 +702,9 @@ int __init tegra_dma_init(void)
writel(0xFFFFFFFFul >> (31 - TEGRA_SYSTEM_DMA_CH_MAX),
addr + APB_DMA_IRQ_MASK_SET);
- memset(channel_usage, 0, sizeof(channel_usage));
- memset(dma_channels, 0, sizeof(dma_channels));
-
- /* Reserve all the channels we are not supposed to touch */
- for (i = 0; i < TEGRA_SYSTEM_DMA_CH_MIN; i++)
- __set_bit(i, channel_usage);
-
for (i = TEGRA_SYSTEM_DMA_CH_MIN; i <= TEGRA_SYSTEM_DMA_CH_MAX; i++) {
struct tegra_dma_channel *ch = &dma_channels[i];
- __clear_bit(i, channel_usage);
-
ch->id = i;
snprintf(ch->name, TEGRA_DMA_NAME_SIZE, "dma_channel_%d", i);
@@ -726,14 +723,15 @@ int __init tegra_dma_init(void)
goto fail;
}
ch->irq = irq;
+
+ __clear_bit(i, channel_usage);
}
/* mark the shared channel allocated */
__set_bit(TEGRA_SYSTEM_DMA_CH_MIN, channel_usage);
- for (i = TEGRA_SYSTEM_DMA_CH_MAX+1; i < NV_DMA_MAX_CHANNELS; i++)
- __set_bit(i, channel_usage);
+ tegra_dma_initialized = true;
- return ret;
+ return 0;
fail:
writel(0, addr + APB_DMA_GEN);
for (i = TEGRA_SYSTEM_DMA_CH_MIN; i <= TEGRA_SYSTEM_DMA_CH_MAX; i++) {
--
1.7.1
^ permalink raw reply related
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Olof Johansson @ 2011-02-23 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF03112A5D95@HQMAIL01.nvidia.com>
On Wed, Feb 23, 2011 at 1:35 PM, Stephen Warren <swarren@nvidia.com> wrote:
> Olof Johansson wrote at Wednesday, February 23, 2011 2:25 PM:
>> On Wed, Feb 23, 2011 at 1:21 PM, Colin Cross <ccross@android.com> wrote:
>> > On Wed, Feb 23, 2011 at 1:08 PM, Olof Johansson <olof@lixom.net> wrote:
>> >> Stephen,
>> >>
>> >> Since this depends on i2c, and registers one of the adapters to do it,
>> >> we should just get the adapters registered separately (all of them)
>> >> before this. I was holding off that part of board code since the i2c
>> >> driver went up that maintainer path instead, but if Colin pulls it
>> >> into tegra for-next, then I'll go ahead with those peices as well.
>> >
>> > I'll merge the i2c-tegra branch into for-next (assuming Ben doesn't
>> > object to it), and you can put all the i2c devices in your pull
>> > request. ?That way we can get everything except this patch into the
>> > first pull request to Linus, and just put this patch into a second
>> > pull request once the ASoC branch is merged.
>>
>> Sure, that works. I'll stage the i2c changes tonight.
>
> OK, so just so I'm clear:
>
> Patches 1..4 are all going in as-is.
>
> I should re-post patch 5 once the merge window is open, having rebased
> it on Olof's i2c registration changes, and
> s/GPIO_WM8903/HARMONY_GPIO_WM8903/. Or, should I repost as soon as Olof
> has updated his branch with the I2C changes, and you'll just hold off
> applying it until the merge window?
How big would the delta be between a patch that would apply (and work)
with current .38-rc wm8903 platform data? If it's just the GPIO base,
we can merge everything but that and just do the small change late in
the merge window.
And yeah, please repost after the i2c stuff is in my branch, I'll
stage it accordingly.
-Olof
^ permalink raw reply
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Stephen Warren @ 2011-02-23 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikmP5H6TQN1v1BNbGTfGokHgyXQ5LbFpEWgWjPB@mail.gmail.com>
Olof Johansson wrote at Wednesday, February 23, 2011 2:52 PM:
>
> On Wed, Feb 23, 2011 at 1:35 PM, Stephen Warren <swarren@nvidia.com> wrote:
> > ...
> > OK, so just so I'm clear:
> >
> > Patches 1..4 are all going in as-is.
> >
> > I should re-post patch 5 once the merge window is open, having rebased
> > it on Olof's i2c registration changes, and
> > s/GPIO_WM8903/HARMONY_GPIO_WM8903/. Or, should I repost as soon as Olof
> > has updated his branch with the I2C changes, and you'll just hold off
> > applying it until the merge window?
>
> How big would the delta be between a patch that would apply (and work)
> with current .38-rc wm8903 platform data? If it's just the GPIO base,
> we can merge everything but that and just do the small change late in
> the merge window.
Once the I2C tree is merged, the only thing needed to make my patch
apply immediately is to remove the gpio_base assignment. I can split
that into a separate patch and post a series if that helps.
> And yeah, please repost after the i2c stuff is in my branch, I'll
> stage it accordingly.
Great, thanks.
--
nvpublic
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Andrei Warkentin @ 2011-02-23 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102231709.05036.arnd@arndb.de>
On Wed, Feb 23, 2011 at 10:09 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 23 February 2011, Andrei Warkentin wrote:
>> That sounds good! In fact, for any quirks enabled for a particular
>> card, I'll expose the tuneables through sysfs attributes, something
>> like /sys/block/mmcblk0/device/quirks/quirk-name/attr-names.
>>
>> Quirks will have block intervals and access size intervals over which
>> they are valid, along with any other quirk-specific parameter.
>> Interval overlap will not be allowed for quirks in the same operation
>> type (r/w/e). The goal here is to make the changes to issue_*_rq as
>> small as possible, and not to pollute block.c at all with the quirks
>> stuff. Quirks are looked up inside issue_*_rq based on req type and
>> [start,end) interval. The resulting found quirks structure will
>> contain a callback used inside issue_*_rq to modify mmc block request
>> structures prior to generating actual MMC commands.
>>
>> Quirks consist of a callback called inside of mmc issue_*_rq,
>> configurable attributes, and the sysfs interface. Quirk groups are
>> defined per-card. At card insertion time, a matching quirk group is
>> found, and is enabled. The quirk group enable function then enables
>> the relevant quirks with the right parameters (adds them to per
>> mmc_blk_data quirk interval tree). Some sane defaults for the tunables
>> are used. If the tunables are modified through sysfs, care is taken
>> that an interval overlap never happens, otherwise the tunable is not
>> modified and a kernel error message is logged.
>>
>> I hope I explained the tentative idea clearly... Thoughts?
>
> I would hope that the quirks can be simpler than this still, without
> the need to call any function pointers while using the device, or
> quirk specific sysfs directories.
>
I'll skip the sysfs part from the first RFC patch. I think this
complicates what I'm trying to achieve and makes this whole thing look
bigger than it is.
> What I meant is to have a single function pointer that can get
> called when detecting a specific known card. All this function
> does is to set values and flags that we can export either through
> common attributes of block devices (e.g. preferred erase size),
> or attributes specific to mmc devices (e.g. the toshiba hack, as
> a bool attribute).
>
> An obvious attribute would be the minimum size of an atomic
> page update. By default this could be 32KB, because any device
> should support that (FAT32 cannot have larger clusters). A
> card specific quirk can set it to another value, like 8KB, 16KB
> or 64KB, and file systems or other tools like mkfs can optimize
> for this value.
>
> I would like the flags like "don't submit requests spanning
> this boundary" and "make all writes below this size" to be defined
> in terms of the regular sizes we already know about, like the
> page size or the erase size.
>
I agree with you on the size/align issues. These are very generic
attributes and don't need a complicated framework like I described to
be dealt with. Ultimately they are just hints to the I/O scheduler, so
they should be part of the block device.
I am more concerned with workarounds that depend on access size (like
the toshiba one) and that modify the MMC commands sent (using reliable
writes, like the Toshiba one, or putting parameters differently like
the Sandisk erase workaround). It's these kinds of workarounds that
the quirks framework is meant to address. I don't think it's a good
idea to pollute mmc_blk_issue_rw_rq and mmc_blk_issue_discard_rq with
if()-elsed workarounds, because it's going to quickly complicate the
logic, and get out of hand and unmanageable the more cards are added.
I'm trying to avoid having to make any changes to card/block.c as part
of making quirk workarounds. The only cost when compared to an if-else
will be one O(log n) quirk lookup, where n is either one or something
close that (since the search is only done for quirks per
mmc_blk_data), and one callback invoked after "brq.data.sg_len =
mmc_queue_map_sg(mq);" so it can patch up mrq as necessary.
^ permalink raw reply
* [PATCHv2 2/2] DM9000B: Fix PHY power for network down/up
From: David Miller @ 2011-02-23 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D642AC6.6050101@henry.nestler.mail.gmail.com>
From: Henry Nestler <henry.nestler@gmail.com>
Date: Tue, 22 Feb 2011 22:29:42 +0100
> DM9000 revision B needs 1 ms delay after PHY power-on.
> PHY must be powered on by writing 0 into register DM9000_GPR before
> all other settings will change (see Davicom spec and example code).
>
> Remember, that register DM9000_GPR was not changed by reset sequence.
>
> Without this fix the FIFO is out of sync and sends wrong data after
> sequence of "ifconfig ethX down ; ifconfig ethX up".
I've applied both of your patches, thanks.
^ permalink raw reply
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Russell King - ARM Linux @ 2011-02-23 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298487532-5000-6-git-send-email-swarren@nvidia.com>
On Wed, Feb 23, 2011 at 11:58:52AM -0700, Stephen Warren wrote:
> +#include <mach/gpio.h>
linux/gpio.h please.
^ permalink raw reply
* [PATCH V5 Resend] ST SPEAr: PCIE gadget suppport
From: Andrew Morton @ 2011-02-24 0:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298276455-23989-1-git-send-email-pratyush.anand@st.com>
On Mon, 21 Feb 2011 13:50:55 +0530
Pratyush Anand <pratyush.anand@st.com> wrote:
> This is a configurable gadget. can be configured by configfs interface. Any
> IP available at PCIE bus can be programmed to be used by host
> controller.It supoorts both INTX and MSI.
> By default, gadget is configured for INTX and SYSRAM1 is mapped to BAR0
> with size 0x1000
>
> Changes since V4:
> - All documentation related comments incorporated
>
> Changes since V3:
> - support for multiple instances of such device
^^ This doesn't seem to agree with the documentation.
> ...
>
> --- /dev/null
> +++ b/Documentation/ABI/testing/configfs-spear-pcie-gadget
> @@ -0,0 +1,30 @@
> +What: /config/pcie-gadget
> +Date: Feb 2011
> +KernelVersion: 2.6.37
> +Contact: Pratyush Anand <pratyush.anand@st.com>
> +Description:
> +
> + Interface is used to configure selected dual mode PCIe controller
> + as device and then program its various registers to configure it
> + as a particular device type.
> + This interfaces can be used to show spear's PCIe device capability.
> +
> + Nodes are only visible when configfs is mounted. To mount configfs
> + in /config directory use:
> + # mount -t configfs none /config/
> +
> + /config/pcie-gadget/
> + link ... used to enable ltssm and read its status.
> + int_type ...used to configure and read type of supported
> + interrupt
> + no_of_msi ... used to configure number of MSI vector needed and
> + to read no of MSI granted.
> + inta ... write 1 to assert INTA and 0 to de-assert.
> + send_msi ... write MSI vector to be sent.
> + vendor_id ... used to write and read vendor id (hex)
> + device_id ... used to write and read device id (hex)
> + bar0_size ... used to write and read bar0_size
> + bar0_address ... used to write and read bar0 mapped area in hex.
> + bar0_rw_offset ... used to write and read offset of bar0 where
> + bar0_data will be written or read.
> + bar0_data ... used to write and read data at bar0_rw_offset.
What's the configfs naming scheme for the second and later devices?
^ permalink raw reply
page: next (older) | 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