Re: Calling irq_set_irq_wake() from .set_irq_wake()?
On 06/05/2015 05:35 AM, Roger Quadros wrote:
Hi,
On Wed, 3 Jun 2015 22:52:47 +0300
Grygorii Strashko grygorii.stras...@ti.com wrote:
Hi Geert,
On 05/19/2015 12:38 PM, Geert Uytterhoeven wrote:
On Mon, May 18, 2015 at 4:52 PM, grygorii.stras...@linaro.org
grygorii.stras...@linaro.org wrote:
On 05/18/2015 05:31 PM, Thomas Gleixner wrote:
On Sun, 17 May 2015, Geert Uytterhoeven wrote:
At least the recursive locking message no longer appears after the
revert.
[ 30.591905] PM: Syncing filesystems ... done.
[ 30.623060] Freezing user space processes ... (elapsed 0.003
seconds) done.
[ 30.634470] Freezing remaining freezable tasks ... (elapsed 0.002
seconds) done.
[ 30.658288] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 30.663678]
[ 30.663681] =
[ 30.663683] [ INFO: possible recursive locking detected ]
[ 30.663688] 4.1.0-rc3 #1115 Not tainted
[ 30.663693] -
[ 30.663697] suspend.sh/2319 is trying to acquire lock:
[ 30.663719] (class){..}, at: [c0096ebc]
__irq_get_desc_lock+0x48/0x88
[ 30.663722]
[ 30.663722] but task is already holding lock:
[ 30.663734] (class){..}, at: [c0096ebc]
__irq_get_desc_lock+0x48/0x88
Does this mean .set_irq_wake() cannot call irq_set_irq_wake()?
It can call it, if it's guaranteed that this wont deadlock.
To tell lockdep that you sure about that, you need to set a different
lock class for the child interrupts. irq_set_lockdep_class() is what
you want to use here.
Hm. Seems we already have corresponding call in gpiochip_irq_map:
static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hwirq)
{
struct gpio_chip *chip = d-host_data;
irq_set_chip_data(irq, chip);
irq_set_lockdep_class(irq, gpiochip_irq_lock_class);
That piece of code sets the lockdep class of the gpiochip's interrupts, not
the parent interrupt.
Found out the hard way by adding some debug code ;-)
[..]
However, I cannot reproduce the problem on sh73a0/kzm9g with
s2ram on a current tree (renesas-drivers-2015-05-19-v4.1-rc4 from
(https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git),
using
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_PROVE_LOCKING=y
Wake-up from gpio-keys works fine, no scary messages.
commit e45d1c80c0eee88e82751461e9cac49d9ed287bc
Author: Linus Walleij linus.wall...@linaro.org
Date: Tue Apr 22 14:01:46 2014 +0200
gpio: put GPIO IRQs into their own lock clas
added in Kernel v3.16
Roger, can you confirm that you've observed this issue with latest kernel,
pls?
Yes please. Thanks!
Issue is reproducible on v4.1-rc6
Unfortunately, I was able to reproduce it, but have no clue how to fix it
gracefully.
lockdep_set_class_and_subclass(..,gpio_chip-base)?
HW configuration which generates lockdep warning:
[SOC GPIO bankA.gpioX] - irq - [pcf875x.gpioY] - irq -
DevZ.enable_irq_wake(pcf_gpioY_irq);
There stacked GPIO chips, but gpiolib uses only one lockdep class for all
GPIOirqchips -
- gpiochip_irq_lock_class.
If this is a gpiolib core issue are we (dra7-evm) the only stacked GPIO users
facing
this problem?
Linus/Alexandre/Geert,
Please advise what can be done for v4.1. The warning is annoying for dra7-evm
users.
Should we temporarily revert the patch even though it is correct and add it
back when the
gpiolib core issue is fixed?
No. Pls. don't do that. See https://lkml.org/lkml/2015/6/3/965
Simple revert is not good solution.
Probably we need to allow GPIO drivers to specify own lockdep class somehow.
--
regards,
-grygorii
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks
Hello Paul, On 01-06-15 19:44, Paul Walmsley wrote: The best way to make this work IMHO would be for us not to accept any new feature addition patches as long as there are warnings reported in the test results. The only real exception that I would foresee is if those warnings are due to something outside of our control, e.g., a crappy bootloader, as I suspect the USB_OTG initiator warnings are for the CM-T3517. I doubt this is related to the bootloader. I have the suspicion that is actually a bug in linux but only triggered depending on whether the ROMcode setup the USB OTG or not. Here is some data to backup my statement: Linux booting without USB_OTG error trap md 480022F0 1 480022f0: 032f /... md 48002580 1 48002580: 0f00b7a2 bit USBOTG_PHY_RESET is 0 - out of reset USB_OTG sees memory hole md 480022F0 1 480022f0: 030f md 48002580 1 48002580: 0f00c71e USBOTG_PHY_RESET is 1 - still in reset when booting linux. Does that match with how your am3517 boards boot? Regards, Jeroen -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks
On 05-06-15 10:01, Jeroen Hofstee wrote: Hello Paul, On 01-06-15 19:44, Paul Walmsley wrote: The best way to make this work IMHO would be for us not to accept any new feature addition patches as long as there are warnings reported in the test results. The only real exception that I would foresee is if those warnings are due to something outside of our control, e.g., a crappy bootloader, as I suspect the USB_OTG initiator warnings are for the CM-T3517. I doubt this is related to the bootloader. I have the suspicion that is actually a bug in linux but only triggered depending on whether the ROMcode setup the USB OTG or not. Here is some data to backup my statement: Linux booting without USB_OTG error trap md 480022F0 1 480022f0: 032f /... md 48002580 1 48002580: 0f00b7a2 bit USBOTG_PHY_RESET is 0 - out of reset USB_OTG sees memory hole md 480022F0 1 480022f0: 030f md 48002580 1 48002580: 0f00c71e USBOTG_PHY_RESET is 1 - still in reset when booting linux. Does that match with how your am3517 boards boot? ps. the dumped register are CONTROL.CONTROL_STATUS and CONTROL.CONTROL_DEVCONF2. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] clk: change clk_ops' -round_rate() prototype
On 05/06/15 00:02, Paul Walmsley wrote: Hi folks just a brief comment on this one: On Thu, 30 Apr 2015, Boris Brezillon wrote: Clock rates are stored in an unsigned long field, but -round_rate() (which returns a rounded rate from a requested one) returns a long value (errors are reported using negative error codes), which can lead to long overflow if the clock rate exceed 2Ghz. Change -round_rate() prototype to return 0 or an error code, and pass the requested rate as a pointer so that it can be adjusted depending on hardware capabilities. ... diff --git a/Documentation/clk.txt b/Documentation/clk.txt index 0e4f90a..fca8b7a 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -68,8 +68,8 @@ the operations defined in clk.h: int (*is_enabled)(struct clk_hw *hw); unsigned long (*recalc_rate)(struct clk_hw *hw, unsigned long parent_rate); -long(*round_rate)(struct clk_hw *hw, -unsigned long rate, +int (*round_rate)(struct clk_hw *hw, +unsigned long *rate, unsigned long *parent_rate); long(*determine_rate)(struct clk_hw *hw, unsigned long rate, I'd suggest that we should probably go straight to 64-bit rates. There are already plenty of clock sources that can generate rates higher than 4GiHz. An alternative would be to introduce to a frequency base the default could be Hz (for backwards compatibility), but for CPUs we probably only care about MHz (or may be kHz) and so 32-bits would still suffice. Even if CPUs cared about Hz they could still use Hz, but in that case they probably don't care about GHz. Obviously, we don't want to break DT compatibility but may be the frequency base could be defined in DT and if it is missing then Hz is assumed. Just a thought ... Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] clk: change clk_ops' -round_rate() prototype
Hi Jon, On Fri, 5 Jun 2015 09:46:09 +0100 Jon Hunter jonath...@nvidia.com wrote: On 05/06/15 00:02, Paul Walmsley wrote: Hi folks just a brief comment on this one: On Thu, 30 Apr 2015, Boris Brezillon wrote: Clock rates are stored in an unsigned long field, but -round_rate() (which returns a rounded rate from a requested one) returns a long value (errors are reported using negative error codes), which can lead to long overflow if the clock rate exceed 2Ghz. Change -round_rate() prototype to return 0 or an error code, and pass the requested rate as a pointer so that it can be adjusted depending on hardware capabilities. ... diff --git a/Documentation/clk.txt b/Documentation/clk.txt index 0e4f90a..fca8b7a 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -68,8 +68,8 @@ the operations defined in clk.h: int (*is_enabled)(struct clk_hw *hw); unsigned long (*recalc_rate)(struct clk_hw *hw, unsigned long parent_rate); - long(*round_rate)(struct clk_hw *hw, - unsigned long rate, + int (*round_rate)(struct clk_hw *hw, + unsigned long *rate, unsigned long *parent_rate); long(*determine_rate)(struct clk_hw *hw, unsigned long rate, I'd suggest that we should probably go straight to 64-bit rates. There are already plenty of clock sources that can generate rates higher than 4GiHz. An alternative would be to introduce to a frequency base the default could be Hz (for backwards compatibility), but for CPUs we probably only care about MHz (or may be kHz) and so 32-bits would still suffice. Even if CPUs cared about Hz they could still use Hz, but in that case they probably don't care about GHz. Obviously, we don't want to break DT compatibility but may be the frequency base could be defined in DT and if it is missing then Hz is assumed. Just a thought ... Yes, but is it really worth the additional complexity. You'll have to add the unit information anyway, so using an unsigned long for the value and another field for the unit (an enum ?) is just like using a 64 bit integer. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: next-20150604 build: 2 failures 37 warnings (next-20150604)
On Thu, Jun 04, 2015 at 10:20:26AM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150604 10:11]: * Mark Brown broo...@kernel.org [150604 10:03]: On Thu, Jun 04, 2015 at 05:47:05PM +0100, Build bot for Mark Brown wrote: arm-allmodconfig ../drivers/tty/serial/8250/8250_omap.c:586:20: error: redefinition of 'omap8250_irq' Current -next fails to build an ARM allmodconfig (and possibly other things) due to 9e91597f24234 and 9809889c708eb (serial: 8250_omap: provide complete custom startup shutdown callbacks) which appear to be the same commit that's been applied twice somehow. Not sure what's going on there... Sounds like I'm using an old commit in one of my pending branches, will check immediately. Greg, there's now commit 9809889c708e in tty-linus and commit 9e91597f2423 in tty-next. Yes, I can't go back and remove the one in tty-next, I'm guessing when they are merged there is an issue. I'll look into that after Linus pulls in my tty-linus tree. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] dmaengine: ti-dma-crossbar: Support for eDMA
On 06/05/2015 06:34 PM, Peter Ujfalusi wrote: Hi, The ti-dma-crossbar driver in it's current form can work when it is used with sDMA (omap-dma). On DRA7x class of devices we have both sDMA and eDMA available. The DT bindings for sDMA has been done in a way that DMA users need to specify the required DMA request number + 1 when they request for channel and the driver stack has been written in this way also for sDMA. Since right now we do not have the crossbar enabled we can still change the compatible string to reflect the crossbar use. The TRM also refers the crossbars in this way. Now that I have sent this series... Would it be better to not touch the compatible strings, but add of_device_id table in the ti-dma-crossbar driver containing the supported dma controllers, like ti,omap4430-sdma and ti,edma3 and to of_match_node() against the node we got via dma-masters? So we would keep the ti,dra7-dma-crossbar and depending on where the dma-masters point us we can decide in the code on how to handle? Just a thought. Regards, Peter --- Misael Lopez Cruz (2): dmaengine: ti-dma-crossbar: Make idr xbar instance-specific dmaengine: ti-dma-crossbar: Add support for eDMA xbar Peter Ujfalusi (1): dmaengine: ti-dma-crossbar: Change the compatible string to ti,dra7-sdma-crossbar Documentation/devicetree/bindings/dma/dma.txt | 2 +- .../devicetree/bindings/dma/ti-dma-crossbar.txt| 5 +-- drivers/dma/ti-dma-crossbar.c | 37 -- 3 files changed, 31 insertions(+), 13 deletions(-) -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/NOT FOR MERGING] HACK: add global/private timers for A9
On Thu, Jun 04, 2015 at 03:20:57PM -0700, Stephen Boyd wrote: On 06/04, Felipe Balbi wrote: On Thu, Jun 04, 2015 at 03:18:25PM -0500, Felipe Balbi wrote: On Thu, Jun 04, 2015 at 03:08:50PM -0500, Felipe Balbi wrote: Hi, On Thu, Jun 04, 2015 at 11:46:59AM +0200, Mason wrote: Also, check /proc/timer_list for a Broadcast device. If you don't define one, the TWD timers are set to periodic mode, with hrtimers disabled. Did you manage to turn global timer into Broadcast device ? arm_global_timer is marked PERCPU, so it will never be chosen as broadcast. Perhaps this is acceptable ? diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c index e6833771a716..8c0170ac367d 100644 --- a/drivers/clocksource/arm_global_timer.c +++ b/drivers/clocksource/arm_global_timer.c @@ -169,8 +169,9 @@ static int gt_clockevents_init(struct clock_event_device *clk) int cpu = smp_processor_id(); clk-name = arm_global_timer; - clk-features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT | - CLOCK_EVT_FEAT_PERCPU; + clk-features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT; + if (is_smp() || setup_max_cpus) + clk-features |= CLOCK_EVT_FEAT_PERCPU; clk-set_mode = gt_clockevent_set_mode; clk-set_next_event = gt_clockevent_set_next_event; clk-cpumask = cpumask_of(cpu); What is this doing? Allowing the global timer to become the broadcast timer? Can you share all the clockevents that are being yeah, as long as have single CPU. registered in the system and what ratings and features they have? Timer List Version: v0.7 HRTIMER_MAX_CLOCK_BASES: 4 now at 126645624877 nsecs cpu: 0 clock 0: .base: eeec36b8 .index: 0 .resolution: 1 nsecs .get_time: ktime_get .offset: 0 nsecs active timers: #0: eeec3970, tick_sched_timer, S:01 # expires at 12664600-12664600 nsecs [in 375123 to 375123 nsecs] #1: def_rt_bandwidth, sched_rt_period_timer, S:01 # expires at 1270-1270 nsecs [in 354375123 to 354375123 nsecs] #2: ed07ff28, hrtimer_wakeup, S:01 # expires at 135190356958-135190406958 nsecs [in 8544732081 to 8544782081 nsecs] #3: ed17bb40, timerfd_tmrproc, S:01 # expires at 136961414000-136961414000 nsecs [in 10315789123 to 10315789123 nsecs] #4: ed17bcc0, timerfd_tmrproc, S:01 # expires at 156961414000-156961414000 nsecs [in 30315789123 to 30315789123 nsecs] #5: ed1fde40, timerfd_tmrproc, S:01 # expires at 157211414000-157211414000 nsecs [in 30565789123 to 30565789123 nsecs] #6: ed143c00, timerfd_tmrproc, S:01 # expires at 180211414000-180211414000 nsecs [in 53565789123 to 53565789123 nsecs] #7: ee43d0c0, timerfd_tmrproc, S:01 # expires at 305461414000-305461414000 nsecs [in 178815789123 to 178815789123 nsecs] #8: ed11fae0, hrtimer_wakeup, S:01 # expires at 606265898975-606365898975 nsecs [in 479620274098 to 479720274098 nsecs] #9: sched_clock_timer, sched_clock_poll, S:01 # expires at 1924145348608-1924145348608 nsecs [in 1797499723731 to 1797499723731 nsecs] clock 1: .base: eeec36f8 .index: 1 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1433450686592811401 nsecs active timers: #0: ee43cc00, timerfd_tmrproc, S:01 # expires at 21474836470-21474836470 nsecs [in 2147483520354375123 to 2147483520354375123 nsecs] clock 2: .base: eeec3738 .index: 2 .resolution: 1 nsecs .get_time: ktime_get_boottime .offset: 0 nsecs active timers: clock 3: .base: eeec3778 .index: 3 .resolution: 1 nsecs .get_time: ktime_get_clocktai .offset: 1433450686592811401 nsecs active timers: .expires_next : 12664600 nsecs .hres_active: 1 .nr_events : 6888 .nr_retries : 0 .nr_hangs : 0 .max_hang_time : 0 nsecs .nohz_mode : 2 .last_tick : 12663900 nsecs .tick_stopped : 0 .idle_jiffies : 4294793935 .idle_calls : 3733 .idle_sleeps: 1759 .idle_entrytime : 126644701595 nsecs .idle_waketime : 12664808 nsecs .idle_exittime : 126640012942 nsecs .idle_sleeptime : 121454496379 nsecs .iowait_sleeptime: 23896349 nsecs .last_jiffies : 4294793940 .next_jiffies : 4294793941 .idle_expires : 12664000 nsecs jiffies: 4294793941 Tick Device: mode: 1 Broadcast device Clock Event Device: arm_global_timer max_delta_ns: 4294967295 min_delta_ns: 1000 mult: 2147483648 shift: 31 mode: 1 next_event: 9223372036854775807 nsecs set_next_event: gt_clockevent_set_next_event set_mode: gt_clockevent_set_mode event_handler: tick_handle_oneshot_broadcast retries:0 tick_broadcast_mask: tick_broadcast_oneshot_mask: Tick Device: mode: 1 Per CPU device: 0 Clock Event Device: local_timer max_delta_ns: 4294967295 min_delta_ns: 1000 mult:
Re: next-20150604 build: 2 failures 37 warnings (next-20150604)
On Fri, Jun 05, 2015 at 07:49:00PM +0900, Greg Kroah-Hartman wrote: On Thu, Jun 04, 2015 at 10:20:26AM -0700, Tony Lindgren wrote: Greg, there's now commit 9809889c708e in tty-linus and commit 9e91597f2423 in tty-next. Yes, I can't go back and remove the one in tty-next, I'm guessing when they are merged there is an issue. I'll look into that after Linus pulls in my tty-linus tree. Yeah, git isn't always spectacularly good at resolving add/add if there's context changes between two things in a merge - it sometimes ends up double adding things. signature.asc Description: Digital signature
[PATCH 3/3] dmaengine: ti-dma-crossbar: Add support for eDMA xbar
From: Misael Lopez Cruz misael.lo...@ti.com
eDMA crossbar works exactly the same way as sDMA, but sDMA
requires an offset of 1, while no offset is needed for eDMA.
Signed-off-by: Misael Lopez Cruz misael.lo...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
.../devicetree/bindings/dma/ti-dma-crossbar.txt| 1 +
drivers/dma/ti-dma-crossbar.c | 30 +-
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
index 76a10d0724b7..da46dddc78ef 100644
--- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
+++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
@@ -2,6 +2,7 @@ Texas Instruments DMA Crossbar (DMA request router)
Required properties:
- compatible: ti,dra7-sdma-crossbar for DRA7xx sDMA crossbar
+ ti,dra7-edma-crossbar for DRA7xx eDMA crossbar
- reg: Memory map for accessing module
- #dma-cells: Should be set to 1.
Clients should use the crossbar request number (input)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 887cfe676b6d..c21690ed954f 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -20,6 +20,9 @@
#define TI_XBAR_OUTPUTS127
#define TI_XBAR_INPUTS 256
+#define TI_XBAR_EDMA_OFFSET0
+#define TI_XBAR_SDMA_OFFSET1
+
struct ti_dma_xbar_data {
void __iomem *iomem;
@@ -29,6 +32,7 @@ struct ti_dma_xbar_data {
u16 safe_val; /* Value to rest the crossbar lines */
u32 xbar_requests; /* number of DMA requests connected to XBAR */
u32 dma_requests; /* number of DMA requests forwarded to DMA */
+ u32 dma_offset;
};
struct ti_dma_xbar_map {
@@ -84,8 +88,7 @@ static void *ti_dma_xbar_route_allocate(struct
of_phandle_args *dma_spec,
GFP_KERNEL);
map-xbar_in = (u16)dma_spec-args[0];
- /* The DMA request is 1 based in sDMA */
- dma_spec-args[0] = map-xbar_out + 1;
+ dma_spec-args[0] = map-xbar_out + xbar-dma_offset;
dev_dbg(pdev-dev, Mapping XBAR%u to DMA%d\n,
map-xbar_in, map-xbar_out);
@@ -95,9 +98,22 @@ static void *ti_dma_xbar_route_allocate(struct
of_phandle_args *dma_spec,
return map;
}
+static const struct of_device_id ti_dma_xbar_match[] = {
+ {
+ .compatible = ti,dra7-sdma-crossbar,
+ .data = (void *)TI_XBAR_SDMA_OFFSET,
+ },
+ {
+ .compatible = ti,dra7-edma-crossbar,
+ .data = (void *)TI_XBAR_EDMA_OFFSET,
+ },
+ {},
+};
+
static int ti_dma_xbar_probe(struct platform_device *pdev)
{
struct device_node *node = pdev-dev.of_node;
+ const struct of_device_id *match;
struct device_node *dma_node;
struct ti_dma_xbar_data *xbar;
struct resource *res;
@@ -108,6 +124,10 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
if (!node)
return -ENODEV;
+ match = of_match_device(ti_dma_xbar_match, pdev-dev);
+ if (!match)
+ return -EINVAL;
+
xbar = devm_kzalloc(pdev-dev, sizeof(*xbar), GFP_KERNEL);
if (!xbar)
return -ENOMEM;
@@ -151,6 +171,7 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
xbar-dmarouter.dev = pdev-dev;
xbar-dmarouter.route_free = ti_dma_xbar_free;
+ xbar-dma_offset = (u32)match-data;
platform_set_drvdata(pdev, xbar);
@@ -169,11 +190,6 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
return ret;
}
-static const struct of_device_id ti_dma_xbar_match[] = {
- { .compatible = ti,dra7-sdma-crossbar },
- {},
-};
-
static struct platform_driver ti_dma_xbar_driver = {
.driver = {
.name = ti-dma-crossbar,
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] dmaengine: ti-dma-crossbar: Change the compatible string to ti,dra7-sdma-crossbar
Currently the driver can be used with sDMA only due to the fact that the
sDMA bindings are using real DMA_REQ + 1 indexing of the DMA requests.
This is not a case with the eDMA for example so the driver in current form
can not handle the case when it is used with eDMA.
Be precise with the compatible.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Documentation/devicetree/bindings/dma/dma.txt | 2 +-
Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt | 4 ++--
drivers/dma/ti-dma-crossbar.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
index 6312fb00ce8d..2ba51ca37cda 100644
--- a/Documentation/devicetree/bindings/dma/dma.txt
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -52,7 +52,7 @@ Optional properties:
Example:
sdma_xbar: dma-router@4a002b78 {
- compatible = ti,dra7-dma-crossbar;
+ compatible = ti,dra7-sdma-crossbar;
reg = 0x4a002b78 0xfc;
#dma-cells = 1;
dma-requests = 205;
diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
index 63a48928f3a8..76a10d0724b7 100644
--- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
+++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
@@ -1,7 +1,7 @@
Texas Instruments DMA Crossbar (DMA request router)
Required properties:
-- compatible: ti,dra7-dma-crossbar for DRA7xx DMA crossbar
+- compatible: ti,dra7-sdma-crossbar for DRA7xx sDMA crossbar
- reg: Memory map for accessing module
- #dma-cells: Should be set to 1.
Clients should use the crossbar request number (input)
@@ -31,7 +31,7 @@ sdma: dma-controller@4a056000 {
/* DMA crossbar */
sdma_xbar: dma-router@4a002b78 {
- compatible = ti,dra7-dma-crossbar;
+ compatible = ti,dra7-sdma-crossbar;
reg = 0x4a002b78 0xfc;
#dma-cells = 1;
dma-requests = 205;
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 24f5ca2356bf..73ecd0a1e312 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -169,7 +169,7 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
}
static const struct of_device_id ti_dma_xbar_match[] = {
- { .compatible = ti,dra7-dma-crossbar },
+ { .compatible = ti,dra7-sdma-crossbar },
{},
};
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] dmaengine: ti-dma-crossbar: Make idr xbar instance-specific
From: Misael Lopez Cruz misael.lo...@ti.com
In preparation for supporting multiple DMA crossbar instances,
make the idr xbar instance specific.
Signed-off-by: Misael Lopez Cruz misael.lo...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/ti-dma-crossbar.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 73ecd0a1e312..887cfe676b6d 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -20,12 +20,11 @@
#define TI_XBAR_OUTPUTS127
#define TI_XBAR_INPUTS 256
-static DEFINE_IDR(map_idr);
-
struct ti_dma_xbar_data {
void __iomem *iomem;
struct dma_router dmarouter;
+ struct idr map_idr;
u16 safe_val; /* Value to rest the crossbar lines */
u32 xbar_requests; /* number of DMA requests connected to XBAR */
@@ -51,7 +50,7 @@ static void ti_dma_xbar_free(struct device *dev, void
*route_data)
map-xbar_in, map-xbar_out);
ti_dma_xbar_write(xbar-iomem, map-xbar_out, xbar-safe_val);
- idr_remove(map_idr, map-xbar_out);
+ idr_remove(xbar-map_idr, map-xbar_out);
kfree(map);
}
@@ -81,7 +80,7 @@ static void *ti_dma_xbar_route_allocate(struct
of_phandle_args *dma_spec,
return ERR_PTR(-ENOMEM);
}
- map-xbar_out = idr_alloc(map_idr, NULL, 0, xbar-dma_requests,
+ map-xbar_out = idr_alloc(xbar-map_idr, NULL, 0, xbar-dma_requests,
GFP_KERNEL);
map-xbar_in = (u16)dma_spec-args[0];
@@ -113,6 +112,8 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
if (!xbar)
return -ENOMEM;
+ idr_init(xbar-map_idr);
+
dma_node = of_parse_phandle(node, dma-masters, 0);
if (!dma_node) {
dev_err(pdev-dev, Can't get DMA master node\n);
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] dmaengine: ti-dma-crossbar: Support for eDMA
Hi, The ti-dma-crossbar driver in it's current form can work when it is used with sDMA (omap-dma). On DRA7x class of devices we have both sDMA and eDMA available. The DT bindings for sDMA has been done in a way that DMA users need to specify the required DMA request number + 1 when they request for channel and the driver stack has been written in this way also for sDMA. Since right now we do not have the crossbar enabled we can still change the compatible string to reflect the crossbar use. The TRM also refers the crossbars in this way. Regards, Peter --- Misael Lopez Cruz (2): dmaengine: ti-dma-crossbar: Make idr xbar instance-specific dmaengine: ti-dma-crossbar: Add support for eDMA xbar Peter Ujfalusi (1): dmaengine: ti-dma-crossbar: Change the compatible string to ti,dra7-sdma-crossbar Documentation/devicetree/bindings/dma/dma.txt | 2 +- .../devicetree/bindings/dma/ti-dma-crossbar.txt| 5 +-- drivers/dma/ti-dma-crossbar.c | 37 -- 3 files changed, 31 insertions(+), 13 deletions(-) -- 2.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] clk: change clk_ops' -round_rate() prototype
Hi Paul, On Thu, 4 Jun 2015 23:02:25 + (UTC) Paul Walmsley p...@pwsan.com wrote: Hi folks just a brief comment on this one: On Thu, 30 Apr 2015, Boris Brezillon wrote: Clock rates are stored in an unsigned long field, but -round_rate() (which returns a rounded rate from a requested one) returns a long value (errors are reported using negative error codes), which can lead to long overflow if the clock rate exceed 2Ghz. Change -round_rate() prototype to return 0 or an error code, and pass the requested rate as a pointer so that it can be adjusted depending on hardware capabilities. ... diff --git a/Documentation/clk.txt b/Documentation/clk.txt index 0e4f90a..fca8b7a 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -68,8 +68,8 @@ the operations defined in clk.h: int (*is_enabled)(struct clk_hw *hw); unsigned long (*recalc_rate)(struct clk_hw *hw, unsigned long parent_rate); - long(*round_rate)(struct clk_hw *hw, - unsigned long rate, + int (*round_rate)(struct clk_hw *hw, + unsigned long *rate, unsigned long *parent_rate); long(*determine_rate)(struct clk_hw *hw, unsigned long rate, I'd suggest that we should probably go straight to 64-bit rates. There are already plenty of clock sources that can generate rates higher than 4GiHz. Yep, that was something I was considering too. If Stephen agrees I'll change that in the next version. BTW, you're referring to the second version of this patch, but things have changed a bit: Stephen recommended to only modify the -determine_rate() prototype and pass a structure instead of a list of arguments. Here is the last version of this series [1]. Best Regards, Boris [1]http://patchwork.linux-mips.org/patch/10092/ -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
