On Fri, Sep 20, 2013 at 11:04:40AM +0530, Kishon Vijay Abraham I wrote:
Hi Greg,
On Tuesday 17 September 2013 09:11 PM, Felipe Balbi wrote:
On Wed, Sep 04, 2013 at 02:27:06PM +0530, Kishon Vijay Abraham I wrote:
On Tuesday 03 September 2013 09:20 PM, Greg KH wrote:
On Tue, Sep 03, 2013
On 20 September 2013 02:33, Nishanth Menon n...@ti.com wrote:
opp_get_opp_count
opp_find_freq_exact
opp_init_cpufreq_table
opp_free_cpufreq_table
The only problem I see is that routines names for few of them are getting
really long now.. Otherwise not much I could find...
Though you had
On 18/09/13 14:08, Archit Taneja wrote:
Some omapdss panels are connected to outputs/encoders(HDMI/DSI/DPI) that
require
regulators. The output's connect op tries to get a regulator which may not
exist
yet because it might get registered later in the kernel boot.
omapdrm currently
On Friday 20 September 2013 01:39 PM, Tomi Valkeinen wrote:
snip
+static int omap_connect_dssdevs(void)
+{
+ int r;
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev) {
+ r = dssdev-driver-connect(dssdev);
+ if (r ==
On 20/09/13 11:49, Archit Taneja wrote:
I suppose we would hit this case if all of the displays are deferred
because of some dependency and are probed after omapdrm probes.
Is that the case with beagle-xm?
Yes, DVI is probed after omapdrm. There's also analog TV out on beagle.
I'm not sure
Hi,
I have a few comments, mostly on the DT binding and parsing.
diff --git a/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/irq-crossbar.txt
new file mode 100644
index 000..5d465cf
--- /dev/null
+++
Hi,
On 09/19/2013 05:17 PM, Sergei Shtylyov wrote:
On 09/19/2013 05:23 PM, Roger Quadros wrote:
Add OCP2SCP1 module address space.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |1 +
1 files changed, 1
Driver core sets driver data to NULL upon failure or remove.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/usb/dwc3/dwc3-pci.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 997ebe4..f41ce36 100644
---
Hi Mark,
On Friday 20 September 2013 02:28 PM, Mark Rutland wrote:
Hi,
I have a few comments, mostly on the DT binding and parsing.
Thanks for the review. The idea of seeing the crossbar as a new IRQCHIP
itself did not go and the latest direction on this was to handle it inside the
GIC.
On Friday 20 September 2013 02:25 PM, Tomi Valkeinen wrote:
On 20/09/13 11:49, Archit Taneja wrote:
I suppose we would hit this case if all of the displays are deferred
because of some dependency and are probed after omapdrm probes.
Is that the case with beagle-xm?
Yes, DVI is probed after
Hi,
On 09/19/2013 05:11 PM, Sergei Shtylyov wrote:
Hello.
On 09/19/2013 05:24 PM, Roger Quadros wrote:
From: Balaji T K balaj...@ti.com
Add support for sata controller.
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Balaji T K balaj...@ti.com
On 20/09/13 13:18, Archit Taneja wrote:
On Friday 20 September 2013 02:25 PM, Tomi Valkeinen wrote:
On 20/09/13 11:49, Archit Taneja wrote:
I suppose we would hit this case if all of the displays are deferred
because of some dependency and are probed after omapdrm probes.
Is that the case
From: Santosh Shilimkar santosh.shilim...@ti.com
Most of the kernel code assumes that max*pfn is maximum pfns because
the physical start of memory is expected to be PFN0. Since this
assumption is not true on ARM architectures, the meaning of max*pfn
is number of memory pages. This is done to keep
From: Santosh Shilimkar santosh.shilim...@ti.com
DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. MMC queue layr
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across
From: Santosh Shilimkar santosh.shilim...@ti.com
DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across
From: Santosh Shilimkar santosh.shilim...@ti.com
Most of the kernel assumes that PFN0 is the start of the physical
memory (RAM). This assumptions is not true on most of the ARM SOCs
and hence and if one try to update the ARM port to follow the assumptions,
we end of breaking the dma bounce limit
From: Santosh Shilimkar santosh.shilim...@ti.com
The blk_queue_bounce_limit() API parameter 'dma_mask' is actually the
maximum address the device can handle rather than a dma_mask. Rename
it accordingly to avoid it being interpreted as dma_mask.
No functional change.
The idea is to fix the bad
This driver doesn't need to directly access DMA masks if it uses the
platform_device_register_full() API rather than
platform_device_register_simple() - the former function can initialize
the DMA mask appropriately.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
We need to start treating DMA masks as something which is specific to
the bus that the device resides on, otherwise we're going to hit all
sorts of nasty issues with LPAE and 32-bit DMA controllers in 32-bit
systems, where memory is offset from PFN 0.
In order to start doing this, we convert the
Use platform_device_register_full() for those drivers which can, to
avoid messing directly with DMA masks. This can only be done when
the driver does not need to access the allocated musb platform device
from within its callbacks, which may be called during the musb
device probing.
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using the correct API.
Signed-off-by:
AMBA Primecell devices always treat streaming and coherent DMA exactly
the same, so there's no point in having the masks separated.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/amba/bus.c |6 +-
drivers/of/platform.c|3 ---
include/linux/amba/bus.h |
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/pl330.c |4
1 files changed, 4 insertions(+), 0
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/emulex/benet/be_main.c | 12 ++--
1
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/sfc/efx.c | 12 +---
1 files changed,
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/staging/et131x/et131x.c | 17 ++---
1 files
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/e1000/e1000_main.c |9 ++---
1
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/block/nvme-core.c | 10 --
1 files changed, 4
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/staging/media/dt3155v4l/dt3155v4l.c |5 +
1 files
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8 ++--
1
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/wireless/b43legacy/dma.c |9 +++--
1 files
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/usb/host/bcma-hcd.c |3 +--
1 files changed, 1
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/video/amba-clcd.c |5 +
1 files changed, 5 insertions(+), 0
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/usb/host/ssb-hcd.c |3 +--
1 files changed, 1
Many drivers contain code such as:
dev-dma_mask = dev-coherent_dma_mask;
dev-coherent_dma_mask = MASK;
Let's move this pattern out of drivers and have the DMA API provide a
helper for it. This helper uses dma_set_mask_and_coherent() to allow
platform issues to be properly dealt
Add a comment to explain why this driver doesn't call any of the DMA
API dma_set_mask() functions.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/usb/host/ohci-sa.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git
This code sequence is unsafe in modules:
static u64 mask = DMA_BIT_MASK(something);
...
if (!dev-dma_mask)
dev-dma_mask = mask;
as if a module is reloaded, the mask will be pointing at the original
module's mask address, and this can lead to oopses. Moreover, they
all
This code sequence:
if (!pdev-dev.dma_mask) {
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(),
Convert this code sequence:
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(64);
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
to use dma_coerce_mask_and_coherent() to avoid bypassing the architecture
check on the DMA mask.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
The code sequence:
isp-raw_dmamask = DMA_BIT_MASK(32);
isp-dev-dma_mask = isp-raw_dmamask;
isp-dev-coherent_dma_mask = DMA_BIT_MASK(32);
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct
On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/wireless/b43/dma.c |9 +++--
1 files changed, 3
On 12:44-20130920, Viresh Kumar wrote:
On 20 September 2013 02:33, Nishanth Menon n...@ti.com wrote:
opp_get_opp_count
opp_find_freq_exact
opp_init_cpufreq_table
opp_free_cpufreq_table
The only problem I see is that routines names for few of them are getting
really long now
The code sequence:
dev-dma_mask = dev-coherent_dma_mask;
dev-coherent_dma_mask = dma_mask;
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King
The code sequence:
pldat-pdev-dev.coherent_dma_mask = 0x;
pldat-pdev-dev.dma_mask = pldat-pdev-dev.coherent_dma_mask;
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
The code sequence:
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(64);
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using the correct API.
Signed-off-by:
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/usb/chipidea/ci_hdrc_imx.c |4 +---
drivers/usb/dwc3/dwc3-exynos.c |4 +---
drivers/usb/host/ehci-atmel.c |4 +---
drivers/usb/host/ehci-omap.c |4 +---
drivers/usb/host/ehci-orion.c |4
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using the correct API.
Signed-off-by:
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/broadcom/b44.c |3 +--
1 files changed, 1
Hi,
On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
Use platform_device_register_full() for those drivers which can, to
avoid messing directly with DMA masks. This can only be done when
the driver does not need to access the allocated musb platform device
from within its
This patch series adding support for OMAP3 ROM Random Number Generator on Nokia
N900.
In previous version I forgot to send patch which changing clk dev id to new
driver name.
Pali Rohár (3):
omap2: Change clk dev id for rng to omap3-rom-rng
hwrng: OMAP3 ROM Random Number Generator support
Name omap_rng is already used by omap_rng driver which is for omap2 and omap4.
For omap3 HS devices there is new driver omap3-rom-rng which needs that clk.
And because there cannot be two drivers with same name, rename omap3 clk dev id.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
Adding this driver as platform device and only for RX-51 until somebody test if
it working also on other OMAP3 HS devices and until there will be generic ARM
way to deal with SMC calls.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 19
This driver provides kernel-side support for the Random Number
Generator hardware found on OMAP34xx processors.
This driver comes from Maemo 2.6.28 kernel and was tested on Nokia RX-51.
It is platform device because it needs board specific function for smc calls.
Signed-off-by: Pali Rohár
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
Hi,
On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
Use platform_device_register_full() for those drivers which can, to
avoid messing directly with DMA masks. This can only be done when
the driver does not need
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote:
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
[...]
-dma_set_coherent_mask() will always be able to set the same or a
-smaller mask as dma_set_mask(). However for the rare case that a
+The coherent coherent mask will
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/amba-pl08x.c |5 +
1 files changed, 5 insertions(+), 0
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/powerpc/kernel/vio.c |3 +--
1 files changed, 1
Don't statically allocate struct device's in modules, and shut the
warning up with an empty release() function. There's a reason that
warning is there and that's not for people to hide in this way. It's
there to persuade people to use the correct APIs to allocate platform
devices.
Hi,
On Fri, Sep 20, 2013 at 02:49:38PM +0100, Russell King - ARM Linux wrote:
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
Hi,
On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
Use platform_device_register_full() for those drivers which can, to
avoid
Hi,
adding Benoit Cousson and linux-omap
On Wed, Aug 14, 2013 at 07:29:59PM +0200, Sebastian Andrzej Siewior wrote:
I forgot to separete the different names in the reg-names property. This
didn't cause anything to fail because the driver does not use the names
and simply relies on the order
On Thu, Aug 15, 2013 at 05:21:50PM +0200, Sebastian Andrzej Siewior wrote:
So I assumed that Beagle bone has only one USB port in host mode because
the micro USB connector had an USB-UART there. I was wrong a little. The
second port runs on host mode, but the micro USB plug is connected to an
On Thu, Aug 15, 2013 at 05:21:51PM +0200, Sebastian Andrzej Siewior wrote:
This is what I observe:
On the first connect, the musb starts with DEVCTL.Session set. On
disconnect, musb_core calls try_idle. That functions removes the Session
bit signalizing that the session is over (something that
Hi,
On Thu, Aug 15, 2013 at 01:18:23PM +0300, Roger Quadros wrote:
The platform data bits can be inferred from the other members of
struct usbhs_phy_data. So get rid of the platform_data member.
Build the platform data for the PHY device in usbhs_init_phys() instead.
Signed-off-by: Roger
+ linux-omap, Benoit
On Thu, Aug 15, 2013 at 05:21:49PM +0200, Sebastian Andrzej Siewior wrote:
This relfects the code and dts requires changes due to recent .dts
binding updates:
- use mg prefix for the Metor Graphics specific attributes
- use power in mA not in mA/2 as specifed in the
Hi,
On Fri, Sep 20, 2013 at 9:08 AM, Nishanth Menon n...@ti.com wrote:
An alternative approach may be to (for all SoCs):
1. define every SoC entry - ti,omap3430 ti,omap3630...
2. have a generic omap3_init which uses if
(of_machine_is_compatible(ti,omap3630))
to invoke the appropriate
* Pali Rohár pali.ro...@gmail.com [130920 06:33]:
Name omap_rng is already used by omap_rng driver which is for omap2 and omap4.
For omap3 HS devices there is new driver omap3-rom-rng which needs that clk.
And because there cannot be two drivers with same name, rename omap3 clk dev
id.
* Felipe Balbi ba...@ti.com [130920 08:52]:
Hi,
On Thu, Aug 15, 2013 at 01:18:23PM +0300, Roger Quadros wrote:
The platform data bits can be inferred from the other members of
struct usbhs_phy_data. So get rid of the platform_data member.
Build the platform data for the PHY device in
On Thu, Sep 19, 2013 at 12:12:44PM -0500, Nishanth Menon wrote:
3.3V fixed regulator does not belong to TPS node - as a result
the fixed regulator is never probed and MMC is continually deferred due
to lack of regulator.
Move the fixed regulator to be at root of platform.
Signed-off-by:
Add generic machine which can handle inits for omap3630.
Currently beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early
This defeats the purpose of having SoC specific init_early handlers,
example: clock nodes are not the same between 3430 and
On Fri, Sep 20, 2013 at 09:18:22AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130920 08:52]:
Hi,
On Thu, Aug 15, 2013 at 01:18:23PM +0300, Roger Quadros wrote:
The platform data bits can be inferred from the other members of
struct usbhs_phy_data. So get rid of the
Hi,
On Fri, Sep 20, 2013 at 09:19:02AM -0700, Olof Johansson wrote:
On Fri, Sep 20, 2013 at 9:08 AM, Nishanth Menon n...@ti.com wrote:
An alternative approach may be to (for all SoCs):
1. define every SoC entry - ti,omap3430 ti,omap3630...
2. have a generic omap3_init which uses if
* Pali Rohár pali.ro...@gmail.com [130919 15:38]:
On Wednesday 18 September 2013 19:42:12 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [130918 09:08]:
On Wednesday 18 September 2013 15:16:44 Pavel Machek wrote:
On Sun 2013-09-08 02:02:52, Aaro Koskinen wrote:
Hi,
On Friday 20 September 2013 18:23:43 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [130920 06:33]:
Name omap_rng is already used by omap_rng driver which is
for omap2 and omap4. For omap3 HS devices there is new
driver omap3-rom-rng which needs that clk. And because
there cannot
On 20 September 2013 18:08, Nishanth Menon n...@ti.com wrote:
I am open to suggestions if any one feels we can improve this better.
I didn't really had one.. I thought of pm_opp** instead of dev_pm_opp**
though..
I believe that change was from Patch #2[1]
Yeah.. I just replied on a single
Hi Balaji,
My test shows that I'm having some timeout in some cases (v3.4.60):
omap_hsmmc omap_hsmmc.0: IRQ Status is 18000
omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO
mmc0: req done (CMD52): -110:
mmc0: starting CMD52 arg 8c08 flags 0195
Hi all,
Here are few patches to make it easier for us to maintain
legacy platform data support while moving to device
tree based booting. It seems that we still have quite a
few places where we still need platform data for omap3
to keep things from breaking.
As the remaining drivers get
We want to drop the board-*.c files but keep things working.
Let's make it a bit easier to support legacy platform data
init with quirks. This also keeps board-generic.c clean from
board specific hacks.
For now, the quirks table is empty, that is populated
in the later patches.
Signed-off-by:
correct mux mode for mmc1_cmd to detect eMMC on bone-black
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
Let's use platform data quirk support for board-generic.c.
This removes all board specific hacks out of board-generic.c.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c | 32 ---
arch/arm/mach-omap2/pdata-quirks.c | 41
On Fri, Sep 20, 2013 at 9:23 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Sep 20, 2013 at 09:19:02AM -0700, Olof Johansson wrote:
On Fri, Sep 20, 2013 at 9:08 AM, Nishanth Menon n...@ti.com wrote:
An alternative approach may be to (for all SoCs):
1. define every SoC entry - ti,omap3430
Let's use the platform data quirk support for wl12xx
and move the board specific code out of devices.c.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c | 38
arch/arm/mach-omap2/pdata-quirks.c | 31
Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
^--- copy and paste error - should of course be
We are moving to device tree based booting, so board-generic
should always be built.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig
Hi,
On Fri, Sep 20, 2013 at 10:16:48AM -0700, Olof Johansson wrote:
On Fri, Sep 20, 2013 at 09:19:02AM -0700, Olof Johansson wrote:
On Fri, Sep 20, 2013 at 9:08 AM, Nishanth Menon n...@ti.com wrote:
An alternative approach may be to (for all SoCs):
1. define every SoC entry -
On Fri, Sep 20, 2013 at 11:08:16PM +0530, Balaji T K wrote:
correct mux mode for mmc1_cmd to detect eMMC on bone-black
Signed-off-by: Balaji T K balaj...@ti.com
Tested on my BBB, I see that after this patch eMMC gets detected just
fine:
Tested-by: Felipe Balbi ba...@ti.com
--
balbi
* Pali Rohár pali.ro...@gmail.com [130920 09:49]:
On Friday 20 September 2013 18:23:43 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [130920 06:33]:
Name omap_rng is already used by omap_rng driver which is
for omap2 and omap4. For omap3 HS devices there is new
driver
* Pali Rohár pali.ro...@gmail.com [130920 11:32]:
On Friday 20 September 2013 19:46:41 Tony Lindgren wrote:
Ok, then there is new patch which only adding omap3-rom-rng and not removing
omap_rng.
It is OK to have same CLK data but with different names?
Yes in this case it's always either
On Friday 20 September 2013 19:46:41 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [130920 09:49]:
On Friday 20 September 2013 18:23:43 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [130920 06:33]:
Name omap_rng is already used by omap_rng driver which
is for omap2
The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.
Usually, the bootloader will configure the control module register, so
probably that's why such support wasn't needed in the past. In suspend
mode though, this
On 09/20/2013 11:51 AM, Viresh Kumar wrote:
On 20 September 2013 18:08, Nishanth Menon n...@ti.com wrote:
I am open to suggestions if any one feels we can improve this better.
I didn't really had one.. I thought of pm_opp** instead of dev_pm_opp**
though..
I had proposed this earlier,
From: Daniel Mack zon...@gmail.com
This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.
Signed-off-by: Daniel Mack zon...@gmail.com
Signed-off-by: Mugunthan V N
This patch series adds the support for configuring GMII_SEL register
of control module to select the phy mode type and also to configure
the clock source for RMII phy mode whether to use internal clock or
the external clock from the phy itself.
Till now CPSW works as this configuration is done in
On 09/20/2013 12:38 PM, Balaji T K wrote:
correct mux mode for mmc1_cmd to detect eMMC on bone-black
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
On Sunday 08 September 2013 10:50:39 Pali Rohár wrote:
This patch will register bq24150a charger in RX-51 board data.
Patch also adding platform function between isp1704 and
bq2415x drivers for detecting charger type.
So finally charging battery on Nokia N900 (RX-51) working
automatically
Phy mode can be configured via the cpsw-phy-sel driver, this patch enabled the
cpsw driver to utilise the api provided by the cpsw-phy-sel driver to configure
the phy mode.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Tested-by: Daniel Mack zon...@gmail.com
---
drivers/net/ethernet/ti/cpsw.c
Add DT entries for the phy mode selection in AM33xx SoC using cpsw-phy-sel
driver.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Tested-by: Daniel Mack zon...@gmail.com
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi
1 - 100 of 105 matches
Mail list logo
