Encapsulate last MTD partition parser argument into a separate
structure. Currently it holds only 'origin' field for RedBoot parser,
but will be extended in future to contain at least device_node for OF
devices.
Lots (nearly all) mtd drivers contain nearly the similar code that
calls parse_mtd_partitions, provides some platform-default values, if
parsing fails, and registers mtd device.
This is an aim to provide single implementation of this scenario:
mtd_device_parse_register() which will handle all this parsing and
defaults.
Richard Zhao [Tue, 15 Nov 2011 06:47:56 +0000 (14:47 +0800)]
clk: add helper functions clk_prepare_enable and clk_disable_unprepare
It's for migrating to generic clk framework API.
The helper functions help cases clk_enable/clk_disable is used
in non-atomic context.
For example, Call clk_enable in probe and clk_disable in remove.
Signed-off-by: Richard Zhao <richard.zhao@linaro.org> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Marek Vasut <marek.vasut@gmail.com>
Russell King [Thu, 22 Sep 2011 10:30:50 +0000 (11:30 +0100)]
clk: provide prepare/unprepare functions
As discussed previously, there's the need on some platforms to run some
parts of clk_enable() in contexts which can schedule. The solution
which was agreed upon was to provide clk_prepare() and clk_unprepare()
to contain this parts, while clk_enable() and clk_disable() perform
the atomic part.
This patch provides a common definition for clk_prepare() and
clk_unprepare() in linux/clk.h, and provides an upgrade path for
existing implementation and drivers: drivers can start using
clk_prepare() and clk_unprepare() once this patch is merged without
having to wait for platform support. Platforms can then start to
provide these additional functions.
Eventually, HAVE_CLK_PREPARE will be removed from the kernel, and
everyone will have to provide these new APIs.
Acked-by: Saravana Kannan <skannan@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Lothar Waßmann [Thu, 8 Dec 2011 08:15:44 +0000 (09:15 +0100)]
dma: mxs-dma: Don't use CLKGATE bits in CTRL0 to disable DMA channels
This is how the original Freescale code (unintentionally) worked,
because the code path which would have asserted the CLKGATE bit was
never actually reached in their code.
This fixes the nefarious "DMA timout" bug when multiple DMA channels
(e.g. GPMI NAND and MMC) are used at the same time.
If a better fix for this problem should be found, the clkgate handling
could be reinstated.
See http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/065228.html
Also reverse the order of mxs_dma_disable_chan() and
mxs_dma_reset_chan() in mxs_dma_control() because mxs_dma_reset_chan()
can only work when the DMA channel is enabled.
Lothar Waßmann [Thu, 8 Dec 2011 08:15:42 +0000 (09:15 +0100)]
dma: mxs-dma: Always leave mxs_dma_init() with the clock disabled.
There is no need to have the clock enabled all the time the driver is
loaded.
It will be enabled anyway in mxs_dma_alloc_chan_resources() when a
channel is actually going to be used.
Other files using dma.h may fail to compile as follows:
In file included from sound/soc/mxs/mxs-pcm.h:22,
from sound/soc/mxs/mxs-saif.h:112,
from sound/soc/mxs/mxs-sgtl5000.c:34:
arch/arm/mach-mxs/include/mach/dma.h:16: warning: 'struct dma_chan' declared inside parameter list
arch/arm/mach-mxs/include/mach/dma.h:16: warning: its scope is only this definition or declaration, which is probably not what you want
arch/arm/mach-mxs/include/mach/dma.h: In function 'mxs_dma_is_apbh':
arch/arm/mach-mxs/include/mach/dma.h:18: error: dereferencing pointer to incomplete type
arch/arm/mach-mxs/include/mach/dma.h: At top level:
arch/arm/mach-mxs/include/mach/dma.h:21: warning: 'struct dma_chan' declared inside parameter list
arch/arm/mach-mxs/include/mach/dma.h: In function 'mxs_dma_is_apbx':
arch/arm/mach-mxs/include/mach/dma.h:23: error: dereferencing pointer to incomplete type
make[3]: *** [sound/soc/mxs/mxs-sgtl5000.o] Error 1
make[2]: *** [sound/soc/mxs] Error 2
make[1]: *** [sound/soc] Error 2
make: *** [sound] Error 2
It seems it's better for dma.h to include dmaengine.h himself.
Shawn Guo [Tue, 13 Dec 2011 15:48:03 +0000 (23:48 +0800)]
dmaengine: add DMA_TRANS_NONE to dma_transfer_direction
Before dma_transfer_direction was introduced to replace
dma_data_direction, some dmaengine device uses DMA_NONE of
dma_data_direction for some talk with its client drivers.
The mxs-dma and its clients mxs-mmc and gpmi-nand are such case.
This patch adds DMA_TRANS_NONE to dma_transfer_direction and
migrate the DMA_NONE use in mxs-dma to it.
It also fixes the compile warning below.
CC drivers/dma/mxs-dma.o
drivers/dma/mxs-dma.c: In function ‘mxs_dma_prep_slave_sg’:
drivers/dma/mxs-dma.c:420:16: warning: comparison between ‘enum dma_transfer_direction’ and ‘enum dma_data_direction’
Paul Gortmaker [Fri, 29 Jul 2011 06:55:11 +0000 (16:55 +1000)]
linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h
The implicit presence of module.h and all its sub-includes was
masking these implicit header usages:
include/linux/dmaengine.h:684: warning: 'struct page' declared inside parameter list
include/linux/dmaengine.h:684: warning: its scope is only this definition or declaration, which is probably not what you want
include/linux/dmaengine.h:687: warning: 'struct page' declared inside parameter list
include/linux/dmaengine.h:736:2: error: implicit declaration of function 'bitmap_zero'
With input from Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Vinod Koul [Thu, 13 Oct 2011 09:45:27 +0000 (15:15 +0530)]
dmaengine: add new enum dma_transfer_direction
This new enum removes usage of dma_data_direction for dma direction. The new
enum cleans tells the DMA direction and mode
This further paves way for merging the dmaengine _prep operations and also for
interleaved dma
Suggested-by: Jassi Brar <jaswinder.singh@linaro.org> Reviewed-by: Barry Song <Baohua.Song@csr.com> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
For clients which require a single slave transfer and dont want to be bothered
about the scatterlist api, this helper gives simple API for this transfer and
creates single scatterlist for DMA API
To prevent mm.h inclusion via other channels also extract "enum dma_data_direction"
definition into separate header. This tiny piece is what gluing netdevice.h with mm.h
via "netdevice.h => dmaengine.h => dma-mapping.h => scatterlist.h => mm.h".
Removal of mm.h from scatterlist.h was tried and was found not feasible
on most archs, so the link was cutoff earlier.
Hope people are OK with tiny include file.
Note, that mm_types.h is still dragged in, but it is a separate story.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Huang Shijie [Wed, 4 Jan 2012 03:18:46 +0000 (11:18 +0800)]
mtd: gpmi-nand bugfix: reset the BCH module when it is not MX23
In MX28, if we do not reset the BCH module. The BCH module may
becomes unstable when the board reboots for several thousands times.
This bug has been catched in customer's production.
The patch adds some comments(some from Wolfram Sang), and fixes it now.
Wolfram Sang [Wed, 23 Nov 2011 14:57:06 +0000 (15:57 +0100)]
mtd: gpmi: add missing include 'module.h'
Fixes:
drivers/mtd/nand/gpmi-nand/gpmi-nand.c: In function 'gpmi_nfc_init':
drivers/mtd/nand/gpmi-nand/gpmi-nand.c:1475:16: error: 'THIS_MODULE' undeclared (first use in this function)
drivers/mtd/nand/gpmi-nand/gpmi-nand.c:1475:16: note: each undeclared identifier is reported only once for each function it appears in
drivers/mtd/nand/gpmi-nand/gpmi-nand.c: At top level:
drivers/mtd/nand/gpmi-nand/gpmi-nand.c:1617:15: error: expected declaration specifiers or '...' before string constant
drivers/mtd/nand/gpmi-nand/gpmi-nand.c:1617:1: warning: data definition has no type or storage class
drivers/mtd/nand/gpmi-nand/gpmi-nand.c:1617:1: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
and some more...
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Huang Shijie <b32955@freescale.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Read esd_csd info each time when cat boot_info
becasue user may change config affect esd_csd
value.
boot_info:0x07;
ALT_BOOT_MODE:1 - Supports alternate boot method
DDR_BOOT_MODE:1 - Supports alternate dual data rate during boot
HS_BOOTMODE:1 - Supports high speed timing during boot
boot_size:0512KB
boot_partition:0x48;
BOOT_ACK:1 - Boot acknowledge sent during boot operation
BOOT_PARTITION-ENABLE: 1 - Boot partition 1 enabled
PARTITION_ACCESS:0 - No access to boot partition
boot_bus:0x01
BOOT_MODE:0 - Use single data rate + backward compatible timings
in boot operation
RESET_BOOT_BUS_WIDTH:0 - Reset bus width to x1, single data rate
and backward compatible timings after boot operation
BOOT_BUS_WIDTH:1 - x4 (sdr/ddr) bus width in boot operation mode
Signed-off-by: Frank Li <Frank.Li@freescale.com> Signed-off-by: Ryan QIAN <b32804@freescale.com>
Enable the configurations of the boot enable on the eMMC cards.
Add the interface that used to configure the boot_bus_width
In order to make sure that the re-read the ext-csd of card
can be completed successfully, add the method to wait for
the finish of the busy state.
NOTE:
The following are the valid inputs when configure the boot
bus width of the eMMC cards.
+--------------------------------------------------------------------+
| Bit7 Bit6 Bit5 | Bit4 Bit3 | Bit2 | Bit1 Bit0 |
|----------------|----------------------------------|----------------|
| X | BOOT_MODE | RESET_BOOT_BUS_WIDTH | BOOT_BUS_WIDTH |
+--------------------------------------------------------------------+
Bit [4:3] : BOOT_MODE (non-volatile)
0x0 : Use single data rate + backward compatible timings in boot
operation (default)
0x1 : Use single data rate + high speed timings in boot operation mode
0x2 : Use dual data rate in boot operation
0x3 : Reserved
Bit [2]: RESET_BOOT_BUS_WIDTH (non-volatile)
0x0 : Reset bus width to x1, single data rate and backward compatible
timings after boot operation (default)
0x1 : Retain boot bus width and boot mode after boot operation
Bit[1:0] : BOOT_BUS_WIDTH (non-volatile)
0x0 : x1 (sdr) or x4 (ddr) bus width in boot operation mode (default)
0x1 : x4 (sdr/ddr) bus width in boot operation mode
0x2 : x8 (sdr/ddr) bus width in boot operation mode
0x3 : Reserved
The following are the valid inputs when configure the boot
partitions of the eMMC cards.
+------------------------------------------------------------+
| Bit7 | Bit6 | Bit5 Bit4 Bit3 | Bit2 Bit1 Bit0 |
|------|----------|-----------------------|------------------|
| X | BOOT_ACK | BOOT_PARTITION_ENABLE | PARTITION_ACCESS |
+------------------------------------------------------------+
Bit7: Reserved
Bit6: always set to vaule '1' when boot_part is enabled
Bit[5:3]:
0x0 : Device not boot enabled (default)
0x1 : Boot partition 1 enabled for boot
0x2 : Boot partition 2 enabled for boot
0x7 : User area enabled for boot
Bit[2:0]:
0x0 : No access to boot partition (default)
0x1 : R/W boot partition 1
0x2 : R/W boot partition 2
So only the '0, 1, 2; 8, 9, 10; 16, 17, 18; 56, 57, 58' are
valid parameters when configure the boot_partiton.
Signed-off-by: Richard Zhu <r65037@freescale.com> Signed-off-by: Ryan QIAN <b32804@freescale.com>
Ryan QIAN [Sat, 7 Jan 2012 04:20:28 +0000 (12:20 +0800)]
ENGR00173283 merge "eMMC: Boot Partition switch func used in MFG tool"
ENGR125411 eMMC: Boot Partition switch func used in MFG tool
User can get eMMC partitions info from user space layer in
linux OS enviroment.
User can do switch operations between the eMMC boot partitions
and the user partition.
User can access the eMMC boot partitions from user space layer
in linux OS enviroment.
NOTE:This func had been verified on TOSHIBA eMMC44 card only.
Signed-off-by: Richard Zhu <r65037@freescale.com> Signed-off-by: Rob Herring <r.herring@freescale.com> Signed-off-by: Ryan QIAN <b32804@freescale.com>
Huang Shijie [Tue, 13 Dec 2011 15:48:05 +0000 (23:48 +0800)]
mtd: fix compile error for gpmi-nand
The driver gpmi-nand should compile at least. This patch adds the
missing gpmi-nand.h to fix the compile error below.
CC drivers/mtd/nand/gpmi-nand/gpmi-nand.o
CC drivers/mtd/nand/gpmi-nand/gpmi-lib.o
drivers/mtd/nand/gpmi-nand/gpmi-nand.c:25:33: fatal error: linux/mtd/gpmi-nand.h: No such file or directory
drivers/mtd/nand/gpmi-nand/gpmi-lib.c:21:33: fatal error: linux/mtd/gpmi-nand.h: No such file or directory
This header is grabbed from patch below, which has not been postponed
for merging.
[PATCH v8 1/4] ARM: mxs: add GPMI-NAND support for imx23/imx28
http://permalink.gmane.org/gmane.linux.drivers.mtd/37338
Adrian Alonso [Wed, 18 Jan 2012 20:56:32 +0000 (14:56 -0600)]
ENGR00172362 mx6q-ard cleanup i2c board settings
* Clean i2c board settings for sabreauto platform
* Remove and unregister i2c0 device not used in this board
* Move i2c3 pads to general mx6q_sabreauto_pads[]
* [v2] add camera module ov3640 module to i2c2 bus
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Danny Nold [Thu, 19 Jan 2012 20:56:33 +0000 (14:56 -0600)]
ENGR00172360-2 - MXC HDMI: New TO1.1 PLL5/PLL4 dividers not set up in clock code
Due to the use of some higher frequencies for HDMI video modes, the
IPU clock set/get/round functions need to use 64-bit variables
for clock calculations instead of 32-bit variables.
Signed-off-by: Danny Nold <dannynold@freescale.com>
Danny Nold [Thu, 19 Jan 2012 20:53:51 +0000 (14:53 -0600)]
ENGR00172360-1 - MXC HDMI: New TO1.1 PLL5/PLL4 dividers not set up in clock co
Update get_rate, set_rate, and round_rate for audio_video PLLs
to account for new dividers added for MX6Q TO1.1. Since default value
for one of these dividers is 4, this is important for function of clocks
derived from PLL4 and PLL5.
Signed-off-by: Danny Nold <dannynold@freescale.com>
For cards that have two or more DAIs, snd_soc_resume's loop over all
DAIs ends up calling schedule_work(deferred_resume_work) once per DAI.
Since this is the same work item each time, the 2nd and subsequent
calls return 0 (work item already queued), and trigger the dev_err
message below stating that a work item may have been lost.
Solve this by adjusting the loop to simply calculate whether to run the
resume work immediately or defer it, and then call schedule work (or not)
one time based on that.
Note: This has not been tested in mainline, but only in chromeos-2.6.38;
mainline doesn't support suspend/resume on Tegra, nor does the mainline
Tegra ASoC driver contain multiple DAIs. It has been compile-checked in
mainline.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
changed the defaut behaviour for non-ac97 class which cause deferred_resume_work
was scheduled not by desire when card->num_rdt is zero.
Jason Liu [Mon, 9 Jan 2012 07:58:11 +0000 (15:58 +0800)]
ENGR00172374-6: fix the mlb modules build errors
/home/r64343/work_space/linux-2.6/drivers/mxc/mlb/mxc_mlb150.c: In function 'mlb_tx_isr':
/home/r64343/work_space/linux-2.6/drivers/mxc/mlb/mxc_mlb150.c:1351: error: 'TASK_INTERRUPTIBLE' undeclared (first use in this function)
/home/r64343/work_space/linux-2.6/drivers/mxc/mlb/mxc_mlb150.c:1351: error: (Each undeclared identifier is reported only once
/home/r64343/work_space/linux-2.6/drivers/mxc/mlb/mxc_mlb150.c:1351: error: for each function it appears in.)
/home/r64343/work_space/linux-2.6/drivers/mxc/mlb/mxc_mlb150.c: In function 'mlb_rx_isr':
/home/r64343/work_space/linux-2.6/drivers/mxc/mlb/mxc_mlb150.c:1400: error: 'TASK_INTERRUPTIBLE' undeclared (first use in this function)
/home/r64343/work_space/linux-2.6/drivers/mxc/mlb/mxc_mlb150.c: In function 'mxc_mlb150_read':
/home/r64343/work_space/linux-2.6/drivers/mxc/mlb/mxc_mlb150.c:1828: error: 'TASK_INTERRUPTIBLE' undeclared (first use in this function)
/home/r64343/work_space/linux-2.6/drivers/mxc/mlb/mxc_mlb150.c:1828: error: implicit declaration of function 'signal_pending'
/home/r64343/work_space/linux-2.6/drivers/mxc/mlb/mxc_mlb150.c:1828: error: implicit declaration of function 'schedule'
missing one header file: sched.h, add it to fix it.
Currently, the gic uses handle_level_irq for handling SPIs (Shared
Peripheral Interrupts), requiring active interrupts to be masked at
the distributor level during IRQ handling.
On a virtualised system, only the CPU interfaces are virtualised in
hardware. Accesses to the distributor must be trapped by the
hypervisor, adding latency to the critical interrupt path in Linux.
This patch modifies the GIC code to use handle_fasteoi_irq for handling
interrupts, which only requires us to signal EOI to the CPU interface
when handling is complete. Cascaded IRQ handling is also updated to use
the chained IRQ enter/exit functions to honour the flow control of the
parent chip.
Note that commit 846afbd1 ("GIC: Dont disable INT in ack callback")
broke cascading interrupts by forgetting to add IRQ masking. This is
no longer an issue because the unmask call is now unnecessary.
Tested on Versatile Express and Realview EB (1176 w/ cascaded GICs).
Tested-and-reviewed-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org> Tested-and-acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
the above commit has removed the irq_ack from gic chip tus the following call:
desc->irq_data.chip->irq_ack(&desc->irq_data);
will trow the kernel oops, to fix it, just involve the pair to fix it.
Jason Liu [Mon, 9 Jan 2012 05:11:57 +0000 (13:11 +0800)]
ENGR00172374-4: remove platform _adjust_dma_zone function
fix the compiling warnings when upgrade to v3.0
arch/arm/mm/init.c:215: warning: 'arm_adjust_dma_zone' defined but not used
The commit: be20902 ARM: use ARM_DMA_ZONE_SIZE to adjust the zone sizes by
Russell has make the _adjust_dma_zone function the common help function, thus
we can remove platform _adjust_dma_zone function by just define:ARM_DMA_ZONE_SIZE
ARM: use ARM_DMA_ZONE_SIZE to adjust the zone sizes
Rather than each platform providing its own function to adjust the
zone sizes, use the new ARM_DMA_ZONE_SIZE definition to perform this
adjustment. This ensures that the actual DMA zone size and the
ISA_DMA_THRESHOLD/MAX_DMA_ADDRESS definitions are consistent with
each other, and moves this complexity out of the platform code.
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Jason Liu <r64343@freescale.com>
Jason Liu [Thu, 19 Jan 2012 06:04:43 +0000 (14:04 +0800)]
ENGR00172374-3: flexcan: use irq_set_irq_wake
fix the building errors when upgrade to v3.0
The following commit change the function name:
commit a0cd9ca2b907d7ee26575e7b63ac92dad768a75e
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Feb 10 11:36:33 2011 +0100
genirq: Namespace cleanup
The irq namespace has become quite convoluted. My bad. Clean it up
and deprecate the old functions. All new functions follow the scheme:
irq number based:
irq_set/get/xxx/_xxx(unsigned int irq, ...)
Now that we have a way to pass MFD cells down to the sub drivers,
we can gradually get rid of mfd_data by putting the platform pointer
back in place.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
But the above commit also change the name from data_size to pdata_size,
This patch just give one fix for the pfuze driver to use pdata_size field.
Jason Liu [Tue, 17 Jan 2012 11:00:30 +0000 (19:00 +0800)]
ENGR00172222:imx6_defconfig: enable ARM errata software workaround 764369
We need enable the following ARM errata software workaround:
CONFIG_ARM_ERRATA_764369=y
This errata is TKT078684 in i.MX6Q errata list.
In order to enable this errata, we need cherry-pick the following commit:
ARM: 7091/1: errata: D-cache line maintenance operation by MVA may not succeed: f64f6df4241093ea928b0a263ec53b93b65efc08
In order to apply the above patch successfully and keep the git history, we also
need cherry-pick the following commit:
Huang Shijie [Mon, 16 Jan 2012 07:01:55 +0000 (15:01 +0800)]
ENGR00169906-5 GPMI : change the code for new interface
If we do not set the WAIT4END in the middle DMA command structure
of the long DMA command chain, a DMA timeout may occurs.
The reason of the DMA timeout is:
[1] We do not set the WAIT4END in the DMA command structure
which do the ECC READ PAGE by the BCH.
[2] So the following DMA command structure (maybe in other DMA
CHAIN)may disable the BCH module.
[3] If the time delay between [2] and [1] is long enough,
it's ok. But if the time delay is not long enough, the BCH
module may become unnormal, so it can not finish its job.
The DMA will timeout in this case.
We have changed the DMA interface to fix the bug, now use the new
interface.
Acked-by: Jason Liu <r64343@freescale.com> Signed-off-by: Huang Shijie <b32955@freescale.com>
But in the NAND ECC read case, the WAIT4END bit should be set
not only at the last DMA Command Structure, but also at the middle one,
such as:
+-----+ +-----+ +-----+
| cmd | ------------> | cmd | ------------------> | cmd |
+-----+ +-----+ +-----+
^ ^
| |
| |
set WAIT4END here too set WAIT4END here
We set the WAIT4END in the middle DMA Command Structure to ensure
the BCH module finishs its job. If we do not wait in this situation,
the BCH module may be changed in the following DMA Command Structures,
and it maybe becomes unstable which will cause a DMA timeout
This has been catched in the MX6Q board.
So rewrite the last parameter of mxs_dma_prep_slave_sg().
Add some more flags to let the driver sets the WAIT4END as it needs.
Acked-by: Jason Liu <r64343@freescale.com> Signed-off-by: Huang Shijie <b32955@freescale.com>
Even Xu [Tue, 17 Jan 2012 02:04:31 +0000 (10:04 +0800)]
ENGR00172175 MX6Q: OV5640_MIPI support fast configure
OV5640_MIPI need to be configure faster to get capture image
quickly. So change the configures, when change the resolution
OV5640_MIPI sensor will not do reset.
Fugang Duan [Wed, 11 Jan 2012 05:34:40 +0000 (13:34 +0800)]
ENGR00171622 - FEC : workaround for Gb enet in sabrelite board.
Micrel phy KSZ9021 Gb speed cannot work well in i.MX6 sabrelite
board. Advertise PHY is not 1000Base-T capable.
If nfs boot kernel, phy will work at 100Mbps, or else phy will
work at Gbps mode. And if hot-plugin cable, phy will work at Gbps
mode. Enet can work well in all of them.
But in Gbps mode, uDMA sometime cannot write frame "L" bit in
exuberate transfer, so driver will print some warning message:
"FEC ENET: rcv is not +last"
Hake Huang [Wed, 11 Jan 2012 10:39:08 +0000 (18:39 +0800)]
ENGR00171792: MX6Q_ARD: fix the pad setting conflicts between can0 and enet
1. need add 'can0' in kernel commandline to enable can1,
the default enet is enabled, can2 is not affected by this.
2. add MX6Q_PAD_SD2_DAT0__GPIO_1_15 back in pad setting,
as this is required for enet rework.
add 4.7k pull down and GPIO_1_15 will reset the u39,
to make it functional, we need pull high.
3. the ENET PHY steering is configured by u39 setting.
Peter Chen [Wed, 11 Jan 2012 03:27:45 +0000 (11:27 +0800)]
ENGR00171544 usb-core: usb host will be broken after system pm test
At i.mx6q sabrelite, there is a usb hub on board. After several
suspend suspend/resume iterations, the usb host will be broken.
It is IC limitation, and similar with: 574b9641d5846e58273dac6bf80fcf1ff312c5c9
Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: make shi <b15407@freescale.com>
Sandor Yu [Mon, 9 Jan 2012 13:23:33 +0000 (21:23 +0800)]
ENGR00171444 HDMI: Change video mode system will hang.
There are two couples register for HDMI PHY interrupt/mask:
HDMI_FC_INT2, HDMI_FC_MASK2 and HDMI_IH_FC_STAT2, HDMI_IH_MUTE_FC_STAT2.
The register can not mixed use it, otherwise the interrupt will missing
and not clean.
Mask interrupt with HDMI_IH_MUTE_FC_STAT2 so check interrupt
should use register HDMI_IH_FC_STAT2.
Alejandro Sierra [Thu, 22 Dec 2011 15:29:55 +0000 (09:29 -0600)]
ENGR00170817 UART2 iomux fix configuration
Added iomux configuration pads to support UART2 through GPIO 7 and GPIO 8
Add flag to enable uart2. This flag avoids configure GPIO7 as CAN mode
when the uart2 is used. The flag is passed through bootargs and is called
uart2.
Signed-off-by: Alejandro Sierra <b18039@freescale.com>
Lothar Waßmann [Mon, 8 Aug 2011 12:47:47 +0000 (14:47 +0200)]
mxs-dma: enable CLKGATE before accessing registers
After calling mxs_dma_disable_chan() for a channel, that channel
becomes unusable because some controller registers can only be written
when the clock is enabled via CLKGATE.
Shawn Guo [Thu, 30 Jun 2011 08:06:33 +0000 (16:06 +0800)]
dmaengine: mxs-dma: skip request_irq for NO_IRQ
In general, the mxs-dma users get separate irq for each channel,
but gpmi is special one which has only one irq shared by all gpmi
channels. It causes mxs_dma channel allocation function fail for
all other gpmi channels except the first one calling into the
function.
The patch gets request_irq call skipped for NO_IRQ case, and leaves
this gpmi specific quirk to gpmi driver to sort out. It will fix
above problem if gpmi driver sets chan_irq as gpmi irq for only one
channel and NO_IRQ for all the rest channels.
Fix CAN1 STBY, EN and STEER pins to be managed through
the IO expander(2) using GPIO's 3,5 and 6. Routes CAN2
TX pin correctly.STEER pin is managed dynamically when
either of the CAN interfaces is UP and/or DOWN.
CAN definitions removed for code clarification.
b37753 [Fri, 6 Jan 2012 21:50:40 +0000 (15:50 -0600)]
ENGR00170444: [v3]imx6sabreauto adv7180 TVin port
Kconfig and Makefile was modified in order to
enable adv7180 driver for mx6q architecture.
adv7180.c mutex was changed to semaphore as is described in
"https://lwn.net/Articles/304725/ ".
sensor data structure is added in fsl_devices.h.
mxc_v4l2_capture.c condition in mxc_v4l2_sparam
was removed because is going to be always true
capture mode only have 1 possible value as is described in
"https://lwn.net/Articles/235023/".
ipu_capture.c clock divisor setup was added at init the csi.
b37753 [Fri, 6 Jan 2012 21:03:08 +0000 (15:03 -0600)]
ENGR00170444: [v3]imx6sabreauto adv7180 TVin port
imx6sabreauto adv7180 TVin port
ioexpanders addresss were incorrect, modification in
board-mx6q_sabreauto.c was done.
adv7180 boot structures and i2c structures were added in board-mx6q_sabreauto.c
i2c3 was not configured properly modified in iomux-mx6q.h.
Francisco Munoz [Fri, 16 Dec 2011 23:16:03 +0000 (17:16 -0600)]
ENGR00170124: Fix for USBH1 OTG IOMUX and GPIOs in board-mx6q_sabreauto.c
USBH1 was not responding to plug events
USBH1 power up settings trough Port Exp B
OTG power up settings trough Port Exp C
Functionality was tested using a mx6qsabreauto cpu board + 53ARD main board
Signed-off-by: Francisco Munoz <b37752@freescale.com>
projects / karo-tx-linux.git / log