default-rate property can now be used to set initial rates for clocks.
This is added by default for all clocks which get initialized through
of_clk_init().
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/clock/clock-bindings.txt |9 ++
drivers/clk/clk.c
default-rate property can now be used to define default rates for clocks,
which get configured during boot.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/prm_common.c |2 ++
drivers/clk/ti/clk.c |1 +
2 files changed, 3 insertions(+)
diff --git
Hi,
This set is a mix-match of new DT properties for generic and TI specific
clock drivers. Basically provided for commenting purposes. The patches
provide a way to configure clock parents / rates during boot through DT.
default-rate : sets rate of a clock during boot, supported for any DT
Setup dpll_usb_ck and dpll_abe_ck using DT properties instead of hardcoding
the parents and rates in kernel.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 12
drivers/clk/ti/clk-44xx.c| 42 --
2 files
ti,mux-clock now supports ti,default-parent property, which can be used
to configure the default parent of the clock during boot. This property
can be added to board specific files, or under the clock data itself.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
On 12/02/14 15:18, Tomi Valkeinen wrote:
However, I hacked together the patch below, which fixes the issue for
96m and dss fclk. It sets the clock parents so that the x2 clocks are
skipped, and makes the x2 clock nodes compatible with unused, making
them effectively disappear. I only verified
On Fri, Jan 24, 2014 at 06:09:41PM +0100, Markus Pargmann wrote:
Currently the info message about a missing wakeirq for uart is printed
every time the serial driver's startup function is called. This happens
multiple times and not just once.
This patch moves the infomessage to the probe
We need to use set-rate-parent for dpll4_m4 clock path, so use the
ti,fixed-factor-clock version which supports set-rate-parent property.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +-
arch/arm/boot/dts/omap3xxx-clocks.dtsi | 6 +++---
2
OMAP3630 DPLL4 is different than on OMAP3430, in that it doesn't have
the x2 multiplier for its outputs. This is not currently reflected in
the clock DT data.
Fix the issue by setting the clock multiplier to 1 (instead of 2) for the
DPLL4 output clocks.
Signed-off-by: Tomi Valkeinen
ti/clk-divider.c does not calculate the rates consistently at the moment.
As an example, on OMAP3 we have a clock divider with a source clock of
86400 Hz. With dividers 6, 7 and 8 the theoretical rates are:
6: 14400
7: 123428571.428571...
8: 10800
Calling clk_round_rate() with the
The DSS fclk and iclk handles are named differently on OMAP3430 ES1 than
on later OMAP revisions. The ES1 has handles 'dss1_alwon_fck_3430es1'
and 'dss_ick_3430es1', whereas later revisions have similar names but
ending with 'es2'.
This means we don't have one clock handle to which we could refer
Hi,
I've been debugging OMAP3 related issues with DSS clocks, and I hopefully have
them all fixed with this series. This fixes the problems for both non-DT boot,
but also for DT boot with DSS DT support (which is not merged yet).
The non-DT boot related fixes should be merged for 3.14, but I'd
Set 'ti,set-rate-parent' property for clocks in the dpll4_m4 clock
path, which is used for DSS functional clock. This fixes DSS driver's
clock rate configuration, which needs the rate to be propagated properly
to the divider node (dpll4_m4_ck).
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
clk: divider: fix rate calculation for fractional rates patch (and
similar for TI specific divider) fixes the clk-divider's rounding. This
patch updates the DSS driver to round the rates accordingly.
This fixes the DSS's warnings about clock rate mismatch, and also fixes
the wrong fclk rate being
clk-divider.c does not calculate the rates consistently at the moment.
As an example, on OMAP3 we have a clock divider with a source clock of
86400 Hz. With dividers 6, 7 and 8 the theoretical rates are:
6: 14400
7: 123428571.428571...
8: 10800
Calling clk_round_rate() with the rate
If CLK_SET_RATE_PARENT is set for a clkoutx2 clock, calling
clk_set_rate() on the clock skips the x2 multiplier as there are no
set_rate and round_rate functions defined for the clkoutx2.
This results in getting double the requested clock rates, breaking the
display on omap3430 based devices.
On 13/02/14 11:03, Tomi Valkeinen wrote:
On 12/02/14 15:18, Tomi Valkeinen wrote:
However, I hacked together the patch below, which fixes the issue for
96m and dss fclk. It sets the clock parents so that the x2 clocks are
skipped, and makes the x2 clock nodes compatible with unused, making
Gumstix is the correct vendor for all Overo related products.
Reported-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-tobi.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Tobi expansion board can be used with both OMAP35xx-based Overo,
and OMAP36xx-based Overo. Currently the boot is broken with newer
OMAP36xx-based Overo (Storm and alike). Fix include file and
compatible string to be able to boot newer models.
This will break older models. This will be addressed
Update the compatible string for Overo/Tobi to reflect the latest
changes.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
Documentation/devicetree/bindings/arm/omap/omap.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Unfortunatly the device tree for older OMAP35xx Overo cannot be used
with newer OMAP36xx and vice-versa. To address this issue, move most of
the Tobi DTS to a common include file, and create model-specific Tobi
DTS.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Tested-by: Kevin Hilman
OMAP36xx-based Overo (Storm and alike) are now failing to boot with 3.14-rc2
[1].
This series fixes this, by moving model-agnostic DT into a common dtsi file,
and creating model-specific DT files:
- omap3-overo-tobi.dts - older OMAP35xx Overo
- omap3-overo-storm-tobi.dts - newer
On 13/02/14 12:04, Tomi Valkeinen wrote:
If CLK_SET_RATE_PARENT is set for a clkoutx2 clock, calling
clk_set_rate() on the clock skips the x2 multiplier as there are no
set_rate and round_rate functions defined for the clkoutx2.
This results in getting double the requested clock rates,
On Thu, Feb 13, 2014 at 11:03 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
I've been debugging OMAP3 related issues with DSS clocks, and I hopefully have
them all fixed with this series. This fixes the problems for both non-DT boot,
but also for DT boot with DSS DT support (which is
On 02/13/2014 04:25 AM, Florian Vaussard wrote:
Tobi expansion board can be used with both OMAP35xx-based Overo,
and OMAP36xx-based Overo. Currently the boot is broken with newer
OMAP36xx-based Overo (Storm and alike). Fix include file and
compatible string to be able to boot newer models.
On 02/13/2014 04:25 AM, Florian Vaussard wrote:
Unfortunatly the device tree for older OMAP35xx Overo cannot be used
with newer OMAP36xx and vice-versa. To address this issue, move most of
the Tobi DTS to a common include file, and create model-specific Tobi
DTS.
Signed-off-by: Florian
On 02/13/2014 04:25 AM, Florian Vaussard wrote:
Gumstix is the correct vendor for all Overo related products.
Reported-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Acked-by: Nishanth Menon n...@ti.com
---
On 02/13/2014 04:25 AM, Florian Vaussard wrote:
Update the compatible string for Overo/Tobi to reflect the latest
changes.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
Documentation/devicetree/bindings/arm/omap/omap.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Signed-off-by: Paolo Pisati paolo.pis...@canonical.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi |9 -
arch/arm/boot/dts/omap4-panda-es.dts |3 ++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
Signed-off-by: Paolo Pisati paolo.pis...@canonical.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi |9 -
arch/arm/boot/dts/omap4-panda-es.dts |3 ++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
* Russell King - ARM Linux li...@arm.linux.org.uk [140210 07:58]:
This is the current set of patches for the OMAP DMA engine rework,
which should now work correctly on OMAP1 platforms thanks to Tony's
testing.
It would be good to get this validated by others across a range of
OMAP
* Santosh Shilimkar santosh.shilim...@ti.com [140114 15:46]:
On Tuesday 14 January 2014 04:13 PM, Nishanth Menon wrote:
I haven't looked at patch myself but as you pointed out if it adds
dead code and makes the code un-readable then probably that something
we shouldn't merge.
Yeah it seems
The OMAP iommu driver performs the reset management for the
iommu instances in processor sub-systems using the omap_device
API which are currently supplied as platform data ops. Use pdata
quirks to maintain the functionality as the OMAP iommu driver
gets converted to use DT nodes, until the reset
From: Florian Vaussard florian.vauss...@epfl.ch
omap_iommu_attach() returns NULL or ERR_PTR in case of error, but
omap_iommu_attach_dev() only checks for IS_ERR. Thus a NULL return value (in
case driver_find_device fails) will cause the kernel to panic when
omap_iommu_attach_dev() dereferences
A new MMU hwmod class and data structures are created
to represent the MMUs within the IPU and DSP processor
subsystems in OMAP5. The MMUs in OMAP5 are identical to
those in OMAP4.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 83
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
The OMAP IOMMU driver locates the IOMMU associated to a device using the
IOMMU name stored in the device archdata iommu field. That field is
expected to be populated by platform code and is left unset for DT-based
devices. This results in a
From: Florian Vaussard florian.vauss...@epfl.ch
When booting with a devicetree, no platform data is provided.
Do not prematurely exit iommu_enable() and iommu_disable() in
such a case.
Note: As OMAP do not yet has a proper reset controller driver,
IOMMUs requiring a reset signal should use
From: Florian Vaussard florian.vauss...@epfl.ch
This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from
the standard bindings used by OMAP peripherals, this patch uses a
'dma-window' (already used by Tegra SMMU) and adds two OMAP custom
bindings - 'ti,#tlb-entries' and
Hi,
This is an updated series to the initial OMAP IOMMU DT driver
adaptation series [1], that primarily dealt with just the OMAP3
ISP MMU. This series is based on 3.14-rc2, and the patches were
developed in collaboration with Florian. I am hoping that the
series can make the 3.15 merge window.
Use the various devm_ interfaces to simplify the cleanup in
probe and remove functions.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/iommu/omap-iommu.c | 52 +-
1 file changed, 10
From: Florian Vaussard florian.vauss...@epfl.ch
As OMAP2+ is moving to a full DT boot for all SoC families, commit
7ce93f3 ARM: OMAP2+: Fix more missing data for omap3.dtsi file
adds basic DT bits for OMAP3. But the driver is not yet converted,
so this will not work and driver will not be probed.
From: Florian Vaussard florian.vauss...@epfl.ch
The device attribute data and ocp address space have all been
cleaned up for OMAP4 iommus. All this data is populated via
the corresponding dt node.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Signed-off-by: Suman Anna s-a...@ti.com
From: Florian Vaussard florian.vauss...@epfl.ch
With full DT boot, the legacy mode of platform device creation
for OMAP IOMMUs is not needed anymore.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/mach-omap2/Makefile | 3 --
arch/arm/mach-omap2/omap-iommu.c | 79
The IVA MMU is not functional when used through the hwmod and
omap_device layers. Add fixes to clockdomain and hwmod data
to have it functional. The hwmod changes are needed to enable
the clock, and the SWSUP change is needed to wakeup the domain
because the power domain is programmed to be in
OMAP5 has the same iommus as OMAP4, so extend the OMAP4
iommu pdata quirks for OMAP5 as well.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/pdata-quirks.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
From: Florian Vaussard florian.vauss...@epfl.ch
CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting
usage by tidspbridge and other iommu users. The same can be achieved
by marking the DT node disabled, so remove this obsolete flag and
the corresponding hwmod data can be enabled.
The IOMMU DT nodes have been added for the DSP and IPU
subsystems. The MMUs in OMAP5 are identical to those in
OMAP4, including the bus error back capability on IPU.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 17 +
1 file changed, 17 insertions(+)
From: Florian Vaussard florian.vauss...@epfl.ch
Add the IOMMU nodes for the DSP and IPU subsystems. The external
address space for DSP starts at 0x2000 in OMAP4 compared to
0x1100 in OMAP3, and the addresses beyond 0xE000 are
private address space for the Cortex-M3 cores in the IPU
From: Florian Vaussard florian.vauss...@epfl.ch
Add the DT node for the IOMMU within the DSP subsystem. The entry
is disabled to keep in line with the current hwmod usage.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: split the entry and disable the node]
Hi,
This series includes patches that adds the iommu DT nodes on
OMAP3 (IVA), and OMAP4 and OMAP5 SoCs. It also includes an
updated OMAP3 ISP iommu DT node patch posted previously [1].
Posting the series separately from the driver DT adapation
changes [2]. The series adds the DTS patches in line
The IOMMU DT adaptation support uses the device name instead
of an iommu object name. The iommu object names should eventually
vanish when all the IOMMU users have been converted to DT nodes.
NOTE: This change is not compatible with legacy boots, but OMAP3
is expected to be DT-boot only going
From: Florian Vaussard florian.vauss...@epfl.ch
The irq numbers, ocp address space and device attribute data
have all been cleaned up for OMAP3 IOMMUs. All this data is
populated via the corresponding dt node.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Signed-off-by: Suman Anna
The remoteproc MMUs in OMAP4+ SoCs have some additional debug
registers that can give out the PC value in addition to the
MMU fault address. The PC value can be extracted properly only
on the DSP cores, and is not available on the ARM processors
within the IPU sub-systems. Instead, the MMUs have
From: Florian Vaussard florian.vauss...@epfl.ch
Update the IOMMU node for the camera subsystem as per the
OMAP IOMMU bindings.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: corrected interrupt number]
Signed-off-by: Suman Anna s-a...@ti.com
---
Hello,
On Wed, Dec 18, 2013 at 11:13:01AM -0600, Felipe Balbi wrote:
On Wed, Dec 18, 2013 at 10:40:58PM +0530, Mugunthan V N wrote:
On Wednesday 18 December 2013 10:38 PM, Felipe Balbi wrote:
On Wed, Dec 18, 2013 at 10:30:55PM +0530, Mugunthan V N wrote:
On Wednesday 18 December 2013
Hello Markus,
On Wed, Dec 18, 2013 at 05:47:20PM +0100, Markus Pargmann wrote:
Use ctrl-macid driver to obtain the macids stored in the processor. This
is only done when defined in DT.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
Documentation/devicetree/bindings/net/cpsw.txt |
On Wed, Dec 18, 2013 at 05:47:19PM +0100, Markus Pargmann wrote:
This driver extracts the hardware macid from the control module of
am335x processors. It exports a function cpsw_ctrl_macid_read for cpsw
to get the macid from within the processor.
This driver is not used, unless it is defined
Hello,
On Wed, Dec 18, 2013 at 05:47:22PM +0100, Markus Pargmann wrote:
Use macids stored in the am335x chip.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
arch/arm/boot/dts/am335x-bone.dts | 8
arch/arm/boot/dts/am335x-boneblack.dts | 8
2 files changed,
* Marc Murphy marcm...@marcm.co.uk [140205 15:20]:
I have now stepped through most of the system as it goes into the sleep
state. It will transition into omap34xx_cpu_suspend and eventually work
itself into an endless loop.
I have then taken a step back to see the config of the system and
* Belisko Marek marek.beli...@gmail.com [140120 12:27]:
Ping? Benoit can you please merge this trivial update. Thanks.
Applying into omap-for-v3.14/fixes thanks.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
* Peter Ujfalusi peter.ujfal...@ti.com [140107 00:16]:
Hi Benoit,
On 12/23/2013 11:28 AM, Peter Ujfalusi wrote:
Hi,
The audio frequency has been incorrectly set in the DTS file which results
incorrect playback frequency on EVM-SK.
The SD card can not be used without the second
* Sebastian Reichel s...@debian.org [140121 06:39]:
update aliases for the ssi clocks ssi_ssr_fck, ssi_sst_fck and ssi_ick
to make them consistent for omap34xx and omap36xx. This makes it
possible to reference the clocks from generic omap3 dts files.
Is this needed as a fix for v3.14-rc? If
* Felipe Balbi ba...@ti.com [140113 10:06]:
If CONFIG_OMAP_32K_TIMER isn't enabled, we will
try to use enable_dyn_sleep which wasn't defined
anywhere.
In order to fix the problem, we always define
enable_dyn_sleep as 0 when !CONFIG_OMAP_32K_TIMER.
Signed-off-by: Felipe Balbi ba...@ti.com
* Markus Pargmann m...@pengutronix.de [140111 06:03]:
The PMIC is using usb0 vbus line as power source. It is also connected
to the am335x processor as vbus sense. But there is no possibility to
pullup usb0 vbus to operate as host. This patch fixes the dr_mode of usb0.
That's the MUSB? AFAIK
* Nishanth Menon n...@ti.com [140129 05:29]:
Hi Tony,
On 01/15/2014 02:00 PM, Nishanth Menon wrote:
OMAP5, DRA7, AM43xx all have OPPs. So select the same to allow SoC
only configuration boot to work with OPP.
Reported-by: Nikhil Devshatwar nikhil...@ti.com
Signed-off-by: Nishanth
* Tomi Valkeinen tomi.valkei...@ti.com [140116 23:47]:
omap2_dpll_round_rate() doesn't actually round the given rate, even if
the name and the description so hints. Instead it only tries to find an
exact rate match, or if that fails, return ~0 as an error.
What this basically means is that
* Nishanth Menon n...@ti.com [140205 06:15]:
On Wed 05 Feb 2014 08:10:34 AM CST, Balaji T K wrote:
Rather than ti,errata.. specific property, something like
caps no/disable multiblock read is more readable in my opinion, Otherwise
Is'nt the better definition to state i have quirk X and
* Marek Belisko ma...@goldelico.com [140125 13:31]:
From: NeilBrown ne...@suse.de
It should be ACTIVE_HIGH.
Signed-off-by: NeilBrown ne...@suse.de
---
arch/arm/boot/dts/omap3-gta04.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
* Marek Belisko ma...@goldelico.com [140125 13:31]:
Does not have an aux supply, and must be non-removable.
Otherwise it is removed during suspend and filesystem gets confused.
Signed-off-by: NeilBrown ne...@suse.de
---
arch/arm/boot/dts/omap3-gta04.dts | 2 +-
1 file changed, 1
* Pekon Gupta pe...@ti.com [140127 22:15]:
Fixes: commit bc6b1e7b86f5d8e4a6fc1c0189e64bba4077efe0
ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
OMAP SoC(s) depend on GPMC controller driver to parse GPMC DT child nodes and
register them platform_device for NAND driver to
* Tomi Valkeinen tomi.valkei...@ti.com [140130 03:19]:
If CLK_SET_RATE_PARENT is set for a clkoutx2 clock, calling
clk_set_rate() on the clock skips the x2 multiplier as there are no
set_rate and round_rate functions defined for the clkoutx2.
This results in getting double the requested
* Nishanth Menon n...@ti.com [140205 01:06]:
omap3_noncore_dpll_set_rate forces a reparent to the same clk_ref
for every call that takes place. This is an can be done only if a change
is detected.
Signed-off-by: Nishanth Menon n...@ti.com
Would like to see acks on this too before applying.
Hi,
On Thu, Feb 13, 2014 at 02:54:38PM -0800, Tony Lindgren wrote:
* Markus Pargmann m...@pengutronix.de [140111 06:03]:
The PMIC is using usb0 vbus line as power source. It is also connected
to the am335x processor as vbus sense. But there is no possibility to
pullup usb0 vbus to operate
* Lokesh Vutla lokeshvu...@ti.com [140207 02:24]:
From: Rajendra Nayak rna...@ti.com
The SyncTimer in AM43x is clocked using the following two sources:
1) An inaccuarte 32k clock (CLK_32KHZ) derived from PER DPLL, causing system
time to go slowly (~10% deviation).
2) external 32KHz RTC
* Aaro Koskinen aaro.koski...@iki.fi [140208 05:52]:
Add platform data for tahvo-usb. This is the last missing piece to get
Tahvo USB working with 3.14.
Applying into omap-for-v3.14/fixes thanks.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
* Nishanth Menon n...@ti.com [140211 12:13]:
On 02/09/2014 06:12 AM, Aaro Koskinen wrote:
N9/N950 does not boot anymore with 3.14-rc1, because SoC compatible
property is missing. Fix that.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Reviewed-by: Nishanth Menon n...@ti.com
* Markus Pargmann m...@pengutronix.de [140213 15:16]:
Hi,
On Thu, Feb 13, 2014 at 02:54:38PM -0800, Tony Lindgren wrote:
* Markus Pargmann m...@pengutronix.de [140111 06:03]:
The PMIC is using usb0 vbus line as power source. It is also connected
to the am335x processor as vbus sense.
* Aaro Koskinen aaro.koski...@iki.fi [140209 11:53]:
Hi,
On Sun, Feb 09, 2014 at 04:01:28PM +0100, Paul Bolle wrote:
The last caller of machine_is_nokia_n800() was removed in commit
5a87cde490e1 (ARM: OMAP2+: Remove legacy booting support for n8x0).
That means that the Kconfig symbol
* Paul Bolle pebo...@tiscali.nl [140212 01:48]:
Commit 97411608fd5f (ARM: OMAP2+: Remove legacy support for zoom
platforms) removed the Kconfig symbols MACH_OMAP_ZOOM2 and
MACH_OMAP_ZOOM3. Remove the last usage of the related macros too.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
* Florian Vaussard florian.vauss...@epfl.ch [140213 02:28]:
OMAP36xx-based Overo (Storm and alike) are now failing to boot with 3.14-rc2
[1].
This series fixes this, by moving model-agnostic DT into a common dtsi file,
and creating model-specific DT files:
- omap3-overo-tobi.dts - older
* Paolo Pisati paolo.pis...@canonical.com [140213 08:00]:
Signed-off-by: Paolo Pisati paolo.pis...@canonical.com
Missing description? Please also Cc Peter Ujfalusi on this
and let me know if this is needed as a fix for the -rc cycle.
Regards,
Tony
---
On Thu, Feb 13, 2014 at 02:49:14PM -0800, Tony Lindgren wrote:
* Sebastian Reichel s...@debian.org [140121 06:39]:
update aliases for the ssi clocks ssi_ssr_fck, ssi_sst_fck and ssi_ick
to make them consistent for omap34xx and omap36xx. This makes it
possible to reference the clocks from
On Thu, 2014-02-13 at 12:05 +0200, Tomi Valkeinen wrote:
On 13/02/14 11:03, Tomi Valkeinen wrote:
On 12/02/14 15:18, Tomi Valkeinen wrote:
However, I hacked together the patch below, which fixes the issue for
96m and dss fclk. It sets the clock parents so that the x2 clocks are
commit 6c31b21 (mmc: omap_hsmmc: remove access to SYSCONFIG register)
introduced an smatch(http://smatch.sf.net) warning for the following:
drivers/mmc/host/omap_hsmmc.c:608 omap_hsmmc_context_restore() warn: add
some parenthesis here?
drivers/mmc/host/omap_hsmmc.c:608
When device is booted using devicetree, platforms impacted by Erratum
2.1.1.128 is not detected easily in the mmc driver. This erratum
indicates that the module cannot do multi-block transfers. Platforms
such as LDP which use OMAP3 ES revision prior to ES3.0 are impacted by
this.
Provide a new
MMC1 is the only MMC interface available on the platform. Further,
since the platform is based on older revision of SoC which is not
capable of doing multi-block reads, mark it with compatibility for the
same and add pinmux to ensure that all relevant pins are configured
for non-MMC boot mode.
Originally reported in: https://patchwork.kernel.org/patch/3514851/
https://patchwork.kernel.org/patch/3514881/
ES3.0+ provides MMC controller which is fixed for multi-block reads,
however LDP platform
Looking at the various IP revision register information:
sdp2430: Revision: 1.2, Spec: 0.0,
On 02/13/2014 05:05 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [140205 06:15]:
On Wed 05 Feb 2014 08:10:34 AM CST, Balaji T K wrote:
Rather than ti,errata.. specific property, something like
caps no/disable multiblock read is more readable in my opinion, Otherwise
Is'nt the
88 matches
Mail list logo
