* Govindraj.R [110531 22:54]:
> Fix the below debug section mismatch warnings.
> while compiling kernel with CONFIG_DEBUG_SECTION_MISMATCH=y
>
> WARNING: vmlinux.o(.data+0x38638): Section mismatch in reference from the
> variable serial*_data to the (unknown reference) .init.data:(unknown)
> The
Hi,
On Thursday, May 26, 2011 4:08 PM, Bedia, Vaibhav wrote:
> The call to pwrdm_wait_transition() in clkdm_clk_enable() is
> redundant since the function pwrdm_clkdm_state_switch() which
> is called next also does the same thing.
>
Any comments on this patch? Can it be merged?
Regards,
Vaibh
* Govindraj.R [110531 22:54]:
> Fix below compilation warnings.
>
> arch/arm/mach-omap2/omap_hwmod.c: In function 'omap_hwmod_for_each':
> arch/arm/mach-omap2/omap_hwmod.c:1631: warning: 'ret' may be used
> uninitialized in this function
>
> arch/arm/mach-omap2/mux.c: In function 'omap_mux_get_
On Wed, Jun 1, 2011 at 12:43 PM, Tony Lindgren wrote:
> * Govindraj.R [110531 22:54]:
>> Fix the below debug section mismatch warnings.
>> while compiling kernel with CONFIG_DEBUG_SECTION_MISMATCH=y
>>
>> WARNING: vmlinux.o(.data+0x38638): Section mismatch in reference from the
>> variable serial
* Balaji T K [110530 07:23]:
> 4 micro seconds is not enough for PBIAS if MMC regulator is
> enabled from MMC regulator OFF.
> Increase the delay for PBIAS to stabilize.
> Wait for PBIAS and timeout if not.
>
> Resolves MMC/SD failure on OMAP4
> "Pbias Voltage is not same as LDO"
>
> Signed-off-
Hi all,
I've marked all the patches as archived in patchwork. The archived patches
can be found at:
http://patchwork.kernel.org/bundle/tmlind/archived-v2.6.39/
You need to select Filters -> Archived -> Yes to see them.
I'm sure we've missed a bunch of patches this merge window because
of the AR
On Wed, Jun 1, 2011 at 1:11 PM, Tony Lindgren wrote:
> * Balaji T K [110530 07:23]:
>> 4 micro seconds is not enough for PBIAS if MMC regulator is
>> enabled from MMC regulator OFF.
>> Increase the delay for PBIAS to stabilize.
>> Wait for PBIAS and timeout if not.
>>
>> Resolves MMC/SD failure o
* stanley.miao [110530 19:19]:
> The test command :
>
> # cyclictest -l1 -m -a0 -t1 -n -p99 -i200 -h200 -q
> I run the following command to increase cpu's burden at the same time.
> # while true; do hackbench; sleep 1;done
>
> cyclictest and hackbench can be get in
> git://git.kernel.org
eMMC does not handle power off when not in sleep state,
Skip regulator disable during probe when eMMC is
not in known state - state left by bootloader.
Resolves eMMC failure on OMAP4
mmc0: error -110 whilst initialising MMC card
Signed-off-by: Balaji T K
Tested-by: Kishore Kadiyala
Acked-by:
Balaji T K (2):
ARM: OMAP4: MMC: increase delay for pbias
ARM: OMAP4: MMC: no regulator off during probe for eMMC
arch/arm/mach-omap2/board-4430sdp.c |1 +
arch/arm/mach-omap2/hsmmc.c | 16 +---
arch/arm/mach-omap2/hsmmc.h |1 +
arch/arm/plat-omap/i
4 micro seconds is not enough for PBIAS if MMC regulator is
enabled from MMC regulator OFF.
Increase the delay for PBIAS to stabilize.
Wait for PBIAS and timeout if not.
Resolves MMC/SD failure on OMAP4
"Pbias Voltage is not same as LDO"
Signed-off-by: Balaji T K
Acked-by: Kishore Kadiyala
---
Hello,
The series will do three major things, and they are in one series, because they
pretty much depending on each other, so it is easier to handle them together.
1. Rename the twl4030-codec MFD driver to twl4030-audio
Since the ASoC multicomponent introduction (2.6.37) the twl4030-codec MFD di
Allign the platform data names for twl4030 audio submodule:
twl4030_audio_data: for the core MFD driver
twl4030_codec_data: for ASoC codec driver
twl4030_vibra_data: for the input/ForceFeedback driver
To avoid breakage, change all depending drivers, files
to use the new types.
Signed-off-by: Pete
Add twl4030_vibra platform data, and the needed regulators
for twl6040 vibrator.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-4430sdp.c | 50 ++-
1 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
From: Misael Lopez Cruz
Add twl6040_vibra as a child of MFD device twl6040_codec. This
implementation covers the PCM-to-PWM mode of TWL6040 vibrator
module.
Signed-off-by: Jorge Eduardo Candelaria
Signed-off-by: Misael Lopez Cruz
Signed-off-by: Peter Ujfalusi
---
drivers/input/misc/Kconfig
Pass twl4030_codec_data instead of the twl4030_audio_data
for the ASoC codec driver.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl6040-core.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/twl6040-core.c b/drivers/mfd/twl6040-core.c
index bb36862..bc
From: Misael Lopez Cruz
Convert TWL6040 CODEC driver into a TWL6040 MFD child, it implies
that MFD-level operations like register accesses, clock setting
and power management are done through MFD APIs, not directly by
CODEC driver anymore. To avoid conflicts with the other MFD child,
vibrator reg
In preparation of renaming the driver from twl4030-codec
to twl4030-audio, first do some clean ups in the driver,
which does not cause any problems outside.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl4030-codec.c | 135 ++-
1 files changed, 68 inser
From: Misael Lopez Cruz
TWL6040 IC provides analog high-end audio codec functions for
handset applications. It contains several audio analog inputs
and outputs as well as vibrator support. It's connected to the
host processor via PDM interface for audio data communication.
The audio modules are c
Rename the driver, and header file from twl4030-codec to
twl4030-audio.
To avoid breakage change depending drivers at the same time.
Signed-off-by: Peter Ujfalusi
CC: Misael Lopez Cruz
---
drivers/input/misc/Kconfig |2 +-
drivers/input/misc/twl4030-vibra.c | 10 +-
drivers/mfd/Kc
On 05/31/11 13:32, Tony Lindgren wrote:
> * Mike Rapoport [110416 15:20]:
>> SMSC911x devices attached to OMAP GPMC always use low level irqs.
>> Setting the appropriate flag in the irq resourse strucure allows using
>> .flags field in the omap_smsc911x_platform_data for driver specific
>> flags
* Igor Grinberg [110601 04:29]:
> On 05/31/11 13:32, Tony Lindgren wrote:
>
> > * Mike Rapoport [110416 15:20]:
> >> SMSC911x devices attached to OMAP GPMC always use low level irqs.
> >> Setting the appropriate flag in the irq resourse strucure allows using
> >> .flags field in the omap_smsc911
* Balaji T K [110601 04:13]:
> 4 micro seconds is not enough for PBIAS if MMC regulator is
> enabled from MMC regulator OFF.
> Increase the delay for PBIAS to stabilize.
> Wait for PBIAS and timeout if not.
>
> Resolves MMC/SD failure on OMAP4
> "Pbias Voltage is not same as LDO"
Thanks for upda
* Peter Ujfalusi [110601 04:14]:
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -463,11 +463,11 @@ static struct regulator_init_data sdp3430_vpll2 = {
> .consumer_supplies = sdp3430_vpll2_supplies,
> };
>
> -static struct twl4030_codec_au
The IOMMU virtual memory mapping API requires page-aligned buffers.
There's no hardware reason behind such a restriction. Remove it by
rounding the address of the first page entry down, and adding the offset
back to the IOMMU virtual address.
Signed-off-by: Laurent Pinchart
Acked-by: Hiroshi DOYU
sg_alloc_table can only allocate multi-page scatter-gather list tables
if the architecture supports scatter-gather lists chaining. ARM doesn't
fit in that category.
The IOMMU driver abuses the sg table structure only to hold page
addresses without ever passing the table to the device.
Use __sg_al
* Laurent Pinchart [110601 05:21]:
> The IOMMU virtual memory mapping API requires page-aligned buffers.
> There's no hardware reason behind such a restriction. Remove it by
> rounding the address of the first page entry down, and adding the offset
> back to the IOMMU virtual address.
Does this o
On Wednesday 01 June 2011 15:07:54 Tony Lindgren wrote:
>
> Can you please take a look at creating arch/arm/mach-omap2/i2c-twl.c or
> something in common-board-devices.c to get rid of the cut and paste
> duplication in every board-*.c file?
Yes, it would make sense, since most of the board has si
* Peter Ujfalusi [110601 05:50]:
> On Wednesday 01 June 2011 15:07:54 Tony Lindgren wrote:
> >
> > Can you please take a look at creating arch/arm/mach-omap2/i2c-twl.c or
> > something in common-board-devices.c to get rid of the cut and paste
> > duplication in every board-*.c file?
>
> Yes, it
On Wednesday 01 June 2011 14:50:24 Tony Lindgren wrote:
> * Laurent Pinchart [110601 05:21]:
> > The IOMMU virtual memory mapping API requires page-aligned buffers.
> > There's no hardware reason behind such a restriction. Remove it by
> > rounding the address of the first page entry down, and add
* Laurent Pinchart [110601 06:04]:
> On Wednesday 01 June 2011 14:50:24 Tony Lindgren wrote:
> > * Laurent Pinchart [110601 05:21]:
> > > The IOMMU virtual memory mapping API requires page-aligned buffers.
> > > There's no hardware reason behind such a restriction. Remove it by
> > > rounding the
* Laurent Pinchart [110601 05:21]:
> sg_alloc_table can only allocate multi-page scatter-gather list tables
> if the architecture supports scatter-gather lists chaining. ARM doesn't
> fit in that category.
>
> The IOMMU driver abuses the sg table structure only to hold page
> addresses without ev
On Wednesday 01 June 2011 16:00:34 Tony Lindgren wrote:
> Yeah, most of it might be possible to describe with just a flags
> like TWL_HAS_VIBRA etc.
Or TWL_BOARD_HAS_VIBRA, TWL_BOARD_HAS_CODEC...
For the audio part it is a bit complicated than that:
different base frequencies, for twl6040 we have
* Tony Lindgren [110601 06:07]:
> * Laurent Pinchart [110601 06:04]:
> > On Wednesday 01 June 2011 14:50:24 Tony Lindgren wrote:
> > > * Laurent Pinchart [110601 05:21]:
> > > > The IOMMU virtual memory mapping API requires page-aligned buffers.
> > > > There's no hardware reason behind such a r
From: Keshava Munegowda
The global suspend and resume functions for usbhs core driver
are implemented.These routine are called when the global suspend
and resume occurs. Before calling these functions, the
bus suspend and resume of ehci and ohci drivers are called
from runtime pm.
Signed-off-by:
The hwmod structure of uhh and tll are retrived
and registered with omap device
Signed-off-by: Keshava Munegowda
---
arch/arm/mach-omap2/usb-host.c | 99 ++--
1 files changed, 35 insertions(+), 64 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/a
From: Keshava Munegowda
device name usbhs clocks are changed from
usbhs-omap.0 to usbhs_omap; this is because
in the hwmod registration the device name is set
as usbhs_omap
Signed-off-by: Keshava Munegowda
---
arch/arm/mach-omap2/clock3xxx_data.c | 28 ++--
arch/arm/m
From: Keshava Munegowda
These set of patches
- defines the hwmod structures of ehci and ohci of omap3 and omap4 socs.
- Implements the Run time pm
- global suspend/resume of EHCI and OHCI
Since, existing omap usbhs core driver of v3.0-rc1 release uses
the run time PM APIs, these patches enable
Following 2 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and
EHCI , OHCI irq and base addresses.
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 184
arch/
The IOMMU virtual memory mapping API requires page-aligned buffers.
There's no hardware reason behind such a restriction. Remove it by
rounding the address of the first page entry down, and adding the offset
back to the IOMMU virtual address.
Signed-off-by: Laurent Pinchart
Acked-by: Hiroshi DOYU
sg_alloc_table can only allocate multi-page scatter-gather list tables
if the architecture supports scatter-gather lists chaining. ARM doesn't
fit in that category.
The IOMMU driver abuses the sg table structure only to hold page
addresses without ever passing the table to the device.
Use __sg_al
Hi,
On Wed, Jun 01, 2011 at 06:57:27PM +0530, Keshava Munegowda wrote:
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 43de12a..32d19e2 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -146,6 +146,10 @@
> #define is_ehci_hsic_mod
* Peter Ujfalusi [110601 06:13]:
> On Wednesday 01 June 2011 16:00:34 Tony Lindgren wrote:
> > Yeah, most of it might be possible to describe with just a flags
> > like TWL_HAS_VIBRA etc.
>
> Or TWL_BOARD_HAS_VIBRA, TWL_BOARD_HAS_CODEC...
>
> For the audio part it is a bit complicated than that:
On Wed, Jun 1, 2011 at 7:01 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jun 01, 2011 at 06:57:27PM +0530, Keshava Munegowda wrote:
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 43de12a..32d19e2 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap
On Wed, Jun 01, 2011 at 03:30:11PM +0200, Laurent Pinchart wrote:
> sg_alloc_table can only allocate multi-page scatter-gather list tables
> if the architecture supports scatter-gather lists chaining. ARM doesn't
> fit in that category.
Let's fix this properly, as I've said countless times and so
On Wed, Jun 1, 2011 at 4:47 PM, Peter Ujfalusi wrote:
> From: Misael Lopez Cruz
>
> TWL6040 IC provides analog high-end audio codec functions for
> handset applications. It contains several audio analog inputs
> and outputs as well as vibrator support. It's connected to the
> host processor via P
Hi Russell,
On Wednesday 01 June 2011 15:43:38 Russell King - ARM Linux wrote:
> On Wed, Jun 01, 2011 at 03:30:11PM +0200, Laurent Pinchart wrote:
> > sg_alloc_table can only allocate multi-page scatter-gather list tables
> > if the architecture supports scatter-gather lists chaining. ARM doesn't
On Wednesday, June 01, 2011, Keshava Munegowda wrote:
> From: Keshava Munegowda
>
> The global suspend and resume functions for usbhs core driver
> are implemented.These routine are called when the global suspend
> and resume occurs. Before calling these functions, the
> bus suspend and resume of
On Wed, Jun 01, 2011 at 03:50:50PM +0200, Laurent Pinchart wrote:
> In the specific iovmm case, the driver uses the sglist API to build a list of
> page-size sg entries, and then process it in software. Is that considered as
> an abuse of the sglist API, or valid usage ?
>
> Anyway, sglist chain
Hi Kevin,
[...]
> > Sorry but omapconf is run from userspace, it cannot be used to dump
> > PRCM registers right before and after MPU WFI.
> >
>
> Right, taking register snapshots is currently beyond the scope of
> omapconf.
>
> However, as I suggested earlier in this thread, if we had a new drive
Hi,
On Wed, Jun 01, 2011 at 03:54:38PM +0200, Rafael J. Wysocki wrote:
> > +static const struct dev_pm_ops usbhsomap_dev_pm_ops = {
> > + .suspend= usbhs_suspend,
> > + .resume = usbhs_resume,
> > +};
>
> Please add .freeze()/.thaw() and .poweroff()/.restore() callbacks too.
>
[adding linux-omap list]
Hello,
Brian Hutchinson writes:
> Hi Kevin,
>
> I caught part of the conversation on the ARM kernel list where it
> looks like gpiolib for OMAP was going to be targeted to 2.6.41 or
> something like that (going from memory).
Actually, the recent discussions were more a
Thanks Kevin!
The TI PSP04.00.00.10 release notes say the 2.6.37 kernel has gpio lib
support added. The previous version of the same kernel that was part
of the previous PSP (4.00.00.09 I think) had the same kernel but
apparently gpiolib was there but wasn't quite all there for the
c6a816x.
Just
Fix a potential NULL pointer dereference by skipping registration of
external entities in case none are provided.
This is useful at least when testing mere memory-to-memory scenarios.
Signed-off-by: Ohad Ben-Cohen
---
drivers/media/video/omap3isp/isp.c |2 +-
1 files changed, 1 insertions(+
From: Julia Lawall
Add missing call to clk_put.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@r exists@
expression e1,e2;
statement S;
@@
e1 = clk_get@p1(...);
... when != e1 = e2
when != clk_put(e1)
when any
if (...
Keshava Munegowda writes:
> Following 2 hwmod strcuture are added:
> UHH hwmod of usbhs with uhh base address and
> EHCI , OHCI irq and base addresses.
> TLL hwmod of usbhs with the TLL base address and irq.
>
> Signed-off-by: Keshava Munegowda
I believe the OMAP4 data came from Benoit, so shou
Hi Kesheva,
Keshava Munegowda writes:
> The hwmod structure of uhh and tll are retrived
> and registered with omap device
>
> Signed-off-by: Keshava Munegowda
Minor comment below...
> ---
> arch/arm/mach-omap2/usb-host.c | 99
> ++--
> 1 files changed,
Keshava Munegowda writes:
> The hwmod structure of uhh and tll are retrived
> and registered with omap device
And the name strings are changed as well as the device identifier
changed from zero to -1. Please comment and justify.
Kevin
--
To unsubscribe from this list: send the line "unsubscrib
Keshava Munegowda writes:
> From: Keshava Munegowda
>
> device name usbhs clocks are changed from
> usbhs-omap.0 to usbhs_omap; this is because
> in the hwmod registration the device name is set
> as usbhs_omap
..and because the identifier is changed to -1 in the previous patch
without being do
On 31.05.2011 15:07, Tony Lindgren wrote:
Care to check if this is still needed for v3.0-rc1? If so, please
add proper patch description and Signed-off-by.
Just tried and successfully built stock 3.0-rc1 kernels with both
configuration combinations. Patch no longer needed.
Cheers,
Matthias
-
Hi Rafael,
Once again, I'm back to some problems with using runtime PM from system
PM methods. On OMAP, many drivers don't need to do anything different
for runtime PM compared to system PM, so the system PM methods can
simply use runtime PM.
The obvious complication arises when runtime PM is di
Keshava Munegowda writes:
> From: Keshava Munegowda
>
> The global suspend and resume functions for usbhs core driver
> are implemented.These routine are called when the global suspend
> and resume occurs. Before calling these functions, the
> bus suspend and resume of ehci and ohci drivers are
Ben,
Please pull in this series from Andy Green for the next merge window.
v4 is simply a rebase of Andy's v3 against v3.0-rc1 with some basic
sanity testing against with the latest kernel.
It's also available here for pulling:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-p
From: Andy Green
Peter Maydell noticed when running under QEMU he was getting
errors reporting 32-bit access to I2C peripheral unit registers
that are documented to be 8 or 16-bit only[1][2]
The I2C driver is blameless as it wraps its accesses in a
function using __raw_writew and __raw_readw, it
From: Andy Green
The OMAP I2C driver dynamically chooses between two register sets of
differing sizes depending on the cpu type it finds itself on.
It has been observed that the existing code references non-existing
registers on OMAP3530, because while it correctly chose the smaller
register lay
From: Andy Green
These represent the two kinds of (incompatible) OMAP I2C
peripheral unit in use so far.
The constants are in linux/i2c-omap.h so the omap i2c driver can have
them too.
Cc: patc...@linaro.org
Cc: Ben Dooks
Reported-by: Peter Maydell
Signed-off-by: Andy Green
Signed-off-by: To
From: Andy Green
We need to pass the I2C IP revision from the hwmod class up
into the OMAP I2C driver, which does not have direct
access to it.
This adds a member to the platform data the OMAP I2C driver
does use already to hold the I2C IP revision.
Cc: patc...@linaro.org
Cc: Ben Dooks
Reporte
From: Andy Green
Since we cannot trust (or even reliably find) the OMAP I2C
peripheral unit's own revision register, we must inform the
OMAP i2c driver of which IP version it is running on. We
do this by tagging the omap_hwmod_class for i2c on all the
OMAP2+ platform / cpu specific hwmod init an
From: Andy Green
All OMAP1 are using "IP revision 1" in terms of register
layout. We set this information in omap1_i2c_add_bus() so
we don't have to use cpu_is_xxx() any more in the omap i2c
driver.
Cc: patc...@linaro.org
Cc: Ben Dooks
Reported-by: Peter Maydell
Signed-off-by: Andy Green
Sig
From: Andy Green
Mark each OMAP I2C bus with the hwmod's knowledge of which I2C
IP version is in the chip we're running on.
Cc: patc...@linaro.org
Cc: Ben Dooks
Reported-by: Peter Maydell
Signed-off-by: Andy Green
Signed-off-by: Tony Lindgren
Signed-off-by: Kevin Hilman
---
arch/arm/plat-o
From: Andy Green
Change the register map names to reflect the IP revision they
are representing, and use the platform_data IP revision index
to select between them at init time.
Eliminates 1 of 17 cpu_...() calls in the driver.
Cc: patc...@linaro.org
Cc: Ben Dooks
Reported-by: Peter Maydell
S
From: Andy Green
This solves the main problem the patch series is about. Prior
to this patch on OMAP3530 the driver wrongly interprets the I2C
peripheral unit's own reported revision as meaning it is running
on an IP V2 device and must use the extended registers.
In fact OMAP3530 is IP V1 with
From: Andy Green
As part of removing cpu_...() from the OMAP I2C driver, we need to
convert the CPU tests into functionality flags that are set by
hwmod class in the same way the IP revision is.
More flags are needed than will fit in the existing u8 flags
member of omap_i2c_dev_attr.
These flag
From: Andy Green
The driver reflects the confusion that probed I2C revision
from the hardware of 0x40 means it is on an OMAP4430.
However, you will probe the same 0x40 ID on an OMAP3530. So
this patch changes the name to reflect that.
It also clarifies that the original name OMAP_I2C_REV_2 is
From: Andy Green
OMAP I2C driver can access the configuration flags through
its platform data.
Cc: patc...@linaro.org
Cc: Ben Dooks
Reported-by: Peter Maydell
Signed-off-by: Andy Green
Signed-off-by: Tony Lindgren
Signed-off-by: Kevin Hilman
---
include/linux/i2c-omap.h |1 +
1 files c
From: Andy Green
This adds the new functionality flags for omap i2c unit to all OMAP2
hwmod definitions
Cc: patc...@linaro.org
Cc: Ben Dooks
Reported-by: Peter Maydell
Signed-off-by: Andy Green
Signed-off-by: Tony Lindgren
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod_2420
From: Andy Green
This patch eliminates all cpu_...() tests from the OMAP I2C driver.
Instead, it uses the functionality flags in the platform data to make
the decisions about product variations the driver needs to handle.
Cc: patc...@linaro.org
Cc: Ben Dooks
Reported-by: Peter Maydell
Signed-
From: Andy Green
The IP version is prepended to the existing printed probed
version as an "epoch" version.
Cc: patc...@linaro.org
Cc: Ben Dooks
Reported-by: Peter Maydell
Signed-off-by: Andy Green
Signed-off-by: Tony Lindgren
Signed-off-by: Kevin Hilman
---
drivers/i2c/busses/i2c-omap.c |
From: Andy Green
This is how the driver can find the flags for its implementation
functionality in its platform_data
Cc: patc...@linaro.org
Cc: Ben Dooks
Reported-by: Peter Maydell
Signed-off-by: Andy Green
Signed-off-by: Tony Lindgren
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/i2c
From: Andy Green
Most of the OMAP1 implementation flags are set statically, with the
exception that omap7xx has its data bus wired up differently.
Cc: patc...@linaro.org
Cc: Ben Dooks
Reported-by: Peter Maydell
Signed-off-by: Andy Green
Signed-off-by: Tony Lindgren
Signed-off-by: Kevin Hilma
From: Andy Green
These represent the 8 kinds of implementation functionality
that up until now were inferred by the 16 remaining cpu_...()
tests in the omap i2c driver.
Cc: patc...@linaro.org
Cc: Ben Dooks
Reported-by: Peter Maydell
Signed-off-by: Andy Green
Signed-off-by: Tony Lindgren
Sign
On Wednesday 01 June 2011 16:38:23 Tony Lindgren wrote:
> But you could easily remove all the board specific struct
> twl4030_codec_data and struct twl4030_codec_audio_data entries by adding a
> default audio init option to omap_pmic_init for the common configuration.
Yeah, I can grep in the board
On Thu, Jun 2, 2011 at 1:26 AM, Kevin Hilman wrote:
> Keshava Munegowda writes:
>
>> Following 2 hwmod strcuture are added:
>> UHH hwmod of usbhs with uhh base address and
>> EHCI , OHCI irq and base addresses.
>> TLL hwmod of usbhs with the TLL base address and irq.
>>
>> Signed-off-by: Keshava
83 matches
Mail list logo
