On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
* Luciano Coelho coe...@ti.com [130117 10:04]:
But this patch is pretty small and simple, so why not include it to at
least fix the breakage in 3.7 and 3.8? Whether you take it or not now
won't make any difference in the 5k LOC in
Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in host mode or in device mode.
Writing to control module registers for doing the above task which was
previously done in omap
Start using the control module driver for powering on the PHY and for
writing to the mailbox instead of writing to the control module
registers on their own.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt |4 ++
A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in host mode or in device mode.
Writing to control module registers for doing the above task which was
previously done in omap
Added has_mailbox to the musb platform data to specify that omap uses
an external mailbox (in control module) to communicate with the musb
core during device connect and disconnect.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |3 +++
Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |4
1 file changed,
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
The dt data specifies among others the interface type (ULPI or UTMI), mode
which is mostly OTG, power that specifies the amount of power this can supply
when in host
This patch series adds dt data to get MUSB working in omap4 and omap3.
Long time back a patch series with the same title was sent but only
a part of it got merged. The rest of it wasn't merged because of
adding omap control usb data to glue and usb phy.
Now there exists a separate driver for
Add omap control usb data in omap4 device tree file. This will have the
register address of registers to power on the PHY and to write to
mailbox.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |8
1 file changed, 8 insertions(+)
diff --git
Hi Tony,
On 01/18/2013 12:16 AM, Tony Lindgren wrote:
Well we are planning to drop the non-DT support for omap4 as soon as it's
usable with DT.
Exactly, but right now we do have legacy and legacy should work in order to
help for example Luca to make the final push which allows us to move to DT
The previous logic to detect the clocks for OMAP4460
was to combine the clocks marked as CK_443X and CK_446X. This would be
fine as long as OMAP4460 was a super set of OMAP4430 clock set.
This is not the case as there are clocks which are specific to OMAP4430
(for example bandgap_fclk) and some
The previous logic to detect the clocks for OMAP4460
was to combine the clocks marked as CK_443X and CK_446X. This would be
fine as long as OMAP4460 was a super set of OMAP4430 clock set.
This is not the case as there are clocks which are specific to OMAP4430
(for example bandgap_fclk) and some
From: Patil, Rachna rac...@ti.com
This patch set is a cumulative set of [1] and [2] sent earlier.
Note that there are no code changes in either of the patch set,
only rebased on top of Linus's v3.8-rc3 tag to make sure that
all the patches apply without any conflicts.
This patch set has been
Hi Paul,
On 01/17/2013 07:43 PM, Paul Walmsley wrote:
The following patch fixes these:
https://lkml.org/lkml/2012/12/24/3
Thanks, I've added that info in the v3.8-rc3 test summary, and moved the
paragraph to the 'resolved by posted patches' section.
FYI: the patch is now in mainline
From: Patil, Rachna rac...@ti.com
Current code has hard coded value written to
step enable bits. Now the bits are updated based
on how many steps are needed to be configured got
from platform data.
The user needs to take care not to exceed
the count more than 16. While using ADC and TSC
one
From: Patil, Rachna rac...@ti.com
Make changes to add DT support in the MFD core driver.
Signed-off-by: Patil, Rachna rac...@ti.com
---
drivers/mfd/ti_am335x_tscadc.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git
From: Patil, Rachna rac...@ti.com
The current driver expected touchscreen input
wires(XP,XN,YP,YN) to be connected in a particular order.
Making changes to accept this as platform data.
Signed-off-by: Patil, Rachna rac...@ti.com
---
drivers/input/touchscreen/ti_am335x_tsc.c | 156
From: Patil, Rachna rac...@ti.com
When touchscreen and ADC are used together, this
unwanted fifo flush leads to loss of ADC data.
Signed-off-by: Patil, Rachna rac...@ti.com
---
drivers/input/touchscreen/ti_am335x_tsc.c | 10 --
1 file changed, 10 deletions(-)
diff --git
From: Patil, Rachna rac...@ti.com
Signed-off-by: Patil, Rachna rac...@ti.com
---
.../devicetree/bindings/mfd/ti_am335x_tscadc.txt | 35
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
diff --git
From: Patil, Rachna rac...@ti.com
Add DT support for client ADC driver.
Signed-off-by: Patil, Rachna rac...@ti.com
---
drivers/iio/adc/ti_am335x_adc.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c
From: Patil, Rachna rac...@ti.com
Add DT support for client touchscreen driver
Signed-off-by: Patil, Rachna rac...@ti.com
---
drivers/input/touchscreen/ti_am335x_tsc.c | 94 +
1 file changed, 81 insertions(+), 13 deletions(-)
diff --git
From: Patil, Rachna rac...@ti.com
Add support for core multifunctional device along
with its clients touchscreen and ADC.
Signed-off-by: Patil, Rachna rac...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 13 +
arch/arm/boot/dts/am33xx.dtsi|8
2 files changed, 21
On Thu, Jan 03, 2013 at 14:07:59, AnilKumar, Chimata wrote:
Adds tps65910 PMIC, lis3lv02d accelerometer, tsl2550 ambient light sensor,
tmp275 temperature sensor, matrix keypad, gbio based leds and D_CAN drivers
support. These peripherals are present on AM33XX family of devices (EVM,
BeagleBone
Hi,
On Tue, Jan 15, 2013 at 02:12:51PM +0530, Kishon Vijay Abraham I wrote:
Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in host mode or in device mode.
Writing to
On Thu, Jan 17, 2013 at 04:44:52PM +0530, kishon wrote:
@@ -171,6 +188,11 @@ static inline void devm_usb_put_phy(struct device
*dev, struct usb_phy *x)
{
}
+static inline struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8
index,
+ const char
On Wed, Jan 16, 2013 at 08:30:56PM +0530, Kishon Vijay Abraham I wrote:
New platforms are being added which has multiple PHY's (of same type) and
which has multiple USB controllers. The binding information has to be
present in the PHY library (otg.c) in order for it to return the
appropriate
On Friday 18 January 2013 05:18 PM, Felipe Balbi wrote:
On Wed, Jan 16, 2013 at 08:30:56PM +0530, Kishon Vijay Abraham I wrote:
New platforms are being added which has multiple PHY's (of same type) and
which has multiple USB controllers. The binding information has to be
present in the PHY
Hi,
On Fri, Jan 18, 2013 at 03:10:42PM +0530, Kishon Vijay Abraham I wrote:
Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in host mode or in device mode.
Writing to
On Fri, Jan 18, 2013 at 03:10:43PM +0530, Kishon Vijay Abraham I wrote:
A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for
Hi,
On Fri, Jan 18, 2013 at 03:10:45PM +0530, Kishon Vijay Abraham I wrote:
Start using the control module driver for powering on the PHY and for
writing to the mailbox instead of writing to the control module
registers on their own.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Hi,
On Friday 18 January 2013 05:29 PM, Felipe Balbi wrote:
Hi,
On Fri, Jan 18, 2013 at 03:10:42PM +0530, Kishon Vijay Abraham I wrote:
Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB
On Friday 18 January 2013 05:32 PM, Felipe Balbi wrote:
Hi,
On Fri, Jan 18, 2013 at 03:10:45PM +0530, Kishon Vijay Abraham I wrote:
Start using the control module driver for powering on the PHY and for
writing to the mailbox instead of writing to the control module
registers on their own.
Hi,
On Fri, Jan 18, 2013 at 05:40:04PM +0530, kishon wrote:
+void omap_control_usb_host_mode(struct device *dev)
+{
+ u32 val;
+ struct omap_control_usb *control_usb = dev_get_drvdata(dev);
+
+ val = AVALID | VBUSVALID;
+
+ writel(val, control_usb-otghs_control);
I would like
Hello.
On 18-01-2013 11:19, Vaibhav Bedia wrote:
Third Party Transfer Controller (TPTC0) needs to be idled and
put to standby under SW control. Add the appropriate flags in
the TPTC0 hwmod entry.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Acked-by: Santosh Shilimkar
On 18-01-2013 11:19, Vaibhav Bedia wrote:
Some of the included header files are not needed so
remove them.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Change from RFC version:
No change
arch/arm/mach-omap2/cm33xx.h |
On Fri, 2013-01-18 at 12:11 +0530, Philip Avinash wrote:
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index eaef5e7..f4209d8 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -393,5 +393,17 @@
ti,hwmods =
Michal == Michal Bachraty michal.bachr...@gmail.com writes:
Hi,
Michal I'm ok with your changes. Have you tried to set MAC from
Michal u-boot? I haven't seen any code for that purpose in cpsw. I
Michal tried put MAC with kernel command parameter (in u-boot), but
Michal nothing happen.
I
Peter == Peter Korsgaard jac...@sunsite.dk writes:
Hi,
Paul Probably the DTS is the right place, since this is a board- and
Paul bootloader-specific quirk. The original intention was to allow
Paul board files to set this HWMOD_INIT_NO_RESET flag themselves - see
Paul mach-omap2/
Enable the use of extmute on the HS path.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index bb73afc..40c22a7 100644
Hi,
I have combined the two previous series for easier handling.
audio via omap-twl4030 for Zoom2 and sdp3430:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/139128.html
PWM support for few boards:
Select the most commonly used audio configuration on boards with twl4030
audio:
Headset, Handsfree output and Line in input
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
Boards with special audio routing can pass a custom omap_tw4030_pdata to the
audio machine driver.
At the same time update the board files using the same audio driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 2 +-
Use the common omap-twl4030 ASoC machine driver for audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
New PWM drivers are being prepared for twl series which will enable the use
of all PWMs (PWMs and LEDs).
They are implemented as generic PWM drivers to be able to use them for different
purposes.
The current platform code was broken: the leds_pwm driver was not able to pick
up the PWM since the
Use the common omap-twl4030 ASoC machine driver for audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
With the PWM backed driver the PMU_STAT led's brighness can be controlled.
This needs the new drivers for the TWL PWM/LED to work.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 39 ++---
1 file changed, 31
The HS extmute is not used on Zoom2 boards. Furthermore the GPIO153 is used
as IRQ for the TSC2004 touchscreen controller - for which we do not have
driver upstream, yet.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 11 +++
1 file
Hi,
Add the needed DT sections for twl4030 and twl6030 for the PWM childs.
Update the omap4-sdp to have working backlight and keypad/charging LED support.
Use the pwm-leds driver on BeagleBoard for the pmu_stat LED instead of the hacky
twl403-gpio mapped PWM.
Regards,
Peter
---
Peter Ujfalusi
Enable support for the PWMs and LEDs as PWM drivers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/twl4030.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index ed0bc95..d216853
Enable support for the PWMs and LED as PWM drivers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/twl6030.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 9996cfc..d9b8b21
We have proper driver stack to handle the pmu_stat LED which is connected
PWMB of twl4030.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git
Sections to describe the pwm-leds in the system.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..8101a94
Section to describe the backlight for the LCD panels.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 8101a94..c2dee41
Paul, Benoit,
Any comments before I resend the serie with the minor comment for Felipe?
Sebastien
On 01/09/2013 04:03 PM, Sebastien Guiriec wrote:
v2:
- Add missing AESS memory banks.
- Update the serie base on comments related earlier serie:
Series contains the hwmod, clock and prm data files for OMAP54xx SOCs.
This data was kept out of tree to be validated on es2.0 silicon version
and also to avoid the es1.0/es2.0 differences which are many.
Benoit Cousson, Rajendra Nayak, Paul Walmesly and Mike have all contributed
to get the
From: Benoit Cousson b-cous...@ti.com
Adding the OMAP5 specific header for SCRM module.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Generated es2.0 data]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Add voltagedomain related data for OMAP54XX SOCs.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/voltage.h |1 +
arch/arm/mach-omap2/voltagedomains54xx_data.c |
From: Benoit Cousson b-cous...@ti.com
Add the PRCM MPU registers for OMAP54XX platforms.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Generated es2.0 data]
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
From: Benoit Cousson b-cous...@ti.com
Add the data file to describe all clock domains inside the OMAP54XX soc.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Generated es2.0 data]
Signed-off-by: Santosh Shilimkar
Include the OMAP5 data files in build. Initialise the voltage, power,
clock domains and the clock tree.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Makefile |6 +-
arch/arm/mach-omap2/io.c |9 +
2
From: Benoit Cousson b-cous...@ti.com
Add the data file to describe all power domains inside the OMAP54XX soc.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
[santosh.shilim...@ti.com: Generated es2.0 data]
Signed-off-by: Santosh Shilimkar
OMAP5 clockdata has different sys clock clock node name. Fix the timer code
to take care of it.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c
Allow prm init to success on OMAP5 SOCs.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/prm44xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index c05a343..1aae198 100644
On OMAP5 to detect invalid/bad memory accesses, 16MB of DDR is used as a trap.
Hence available memory for linux OS is 2032 MB on boards popullated with 2 GB
memory.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts
From: Rajendra Nayak rna...@ti.com
Specify both secure as well as nonsecure PPI IRQ for arch
timer. This fixes the following errors seen on DT OMAP5 boot..
[0.00] arch_timer: No interrupt available, giving up
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Rajendra Nayak
Hi Paul,
On 01/17/2013 05:24 PM, Paul Walmsley wrote:
Here's the updated version (at the bottom of this message). Seems to work
based on a quick test on 2430SDP.
# shutdown -r -n now
shutdown: sending all processes the TERM signal...
shutdown: sending all processes the KILL signal.
On 18/01/13 15:32, Santosh Shilimkar wrote:
From: Rajendra Nayak rna...@ti.com
Specify both secure as well as nonsecure PPI IRQ for arch
timer. This fixes the following errors seen on DT OMAP5 boot..
[0.00] arch_timer: No interrupt available, giving up
Cc: Benoit Cousson
On Friday 18 January 2013 09:32 PM, Marc Zyngier wrote:
On 18/01/13 15:32, Santosh Shilimkar wrote:
From: Rajendra Nayak rna...@ti.com
Specify both secure as well as nonsecure PPI IRQ for arch
timer. This fixes the following errors seen on DT OMAP5 boot..
[0.00] arch_timer: No
On 18/01/13 17:00, Santosh Shilimkar wrote:
On Friday 18 January 2013 09:32 PM, Marc Zyngier wrote:
On 18/01/13 15:32, Santosh Shilimkar wrote:
From: Rajendra Nayak rna...@ti.com
Specify both secure as well as nonsecure PPI IRQ for arch
timer. This fixes the following errors seen on DT OMAP5
Hi,
* Santosh Shilimkar santosh.shilim...@ti.com [130118 07:30]:
From: Benoit Cousson b-cous...@ti.com
Adding the hwmod data for OMAP54xx platforms.
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+/* bb2d */
+static struct omap_hwmod_irq_info omap54xx_bb2d_irqs[] = {
+
* Santosh Shilimkar santosh.shilim...@ti.com [130118 07:30]:
From: Rajendra Nayak rna...@ti.com
Add the clock tree related data for OMAP54xx platforms.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
* Luciano Coelho coe...@ti.com [130118 01:03]:
On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
* Luciano Coelho coe...@ti.com [130117 10:04]:
But this patch is pretty small and simple, so why not include it to at
least fix the breakage in 3.7 and 3.8? Whether you take it or not
* Peter Ujfalusi peter.ujfal...@ti.com [130118 02:15]:
Hi Tony,
On 01/18/2013 12:16 AM, Tony Lindgren wrote:
Well we are planning to drop the non-DT support for omap4 as soon as it's
usable with DT.
Exactly, but right now we do have legacy and legacy should work in order to
help for
Other devices in the device tree can use omap-gpio as an interrupt
controller with something like:
interrupt-parent = gpio1;
interrupts = 19 8;
(in this case with #interrupt-cells = 2 in the gpio node to be able
to configure the IRQ flags in DT)
Currently this triggers an
Hi,
On Fri, Jan 18, 2013 at 09:36:35AM -0800, Tony Lindgren wrote:
* Luciano Coelho coe...@ti.com [130118 01:03]:
On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
* Luciano Coelho coe...@ti.com [130117 10:04]:
But this patch is pretty small and simple, so why not include it to at
* Felipe Balbi ba...@ti.com [130118 09:57]:
Hi,
On Fri, Jan 18, 2013 at 09:36:35AM -0800, Tony Lindgren wrote:
* Luciano Coelho coe...@ti.com [130118 01:03]:
On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
* Luciano Coelho coe...@ti.com [130117 10:04]:
But this patch is
On Friday 18 January 2013 10:38 PM, Marc Zyngier wrote:
On 18/01/13 17:00, Santosh Shilimkar wrote:
On Friday 18 January 2013 09:32 PM, Marc Zyngier wrote:
On 18/01/13 15:32, Santosh Shilimkar wrote:
From: Rajendra Nayak rna...@ti.com
Specify both secure as well as nonsecure PPI IRQ for arch
On Fri, 2013-01-18 at 09:36 -0800, Tony Lindgren wrote:
* Luciano Coelho coe...@ti.com [130118 01:03]:
On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
* Luciano Coelho coe...@ti.com [130117 10:04]:
But this patch is pretty small and simple, so why not include it to at
least
* Luciano Coelho coe...@ti.com [130118 11:12]:
On Fri, 2013-01-18 at 09:36 -0800, Tony Lindgren wrote:
* Luciano Coelho coe...@ti.com [130118 01:03]:
On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
* Luciano Coelho coe...@ti.com [130117 10:04]:
But this patch is pretty small
Tony,
On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren t...@atomide.com wrote:
* Daniel Mack zon...@gmail.com [130114 15:30]:
On Jan 15, 2013 2:06 AM, Tony Lindgren t...@atomide.com wrote:
* Ezequiel Garcia elezegar...@gmail.com [121223 13:49]:
On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack
OPP pointer is RCU protected, hence after finding it, de-reference
also should be protected with the same RCU context else the OPP
pointer may become invalid.
Reported-by: Alexander Holler hol...@ahsoftware.de
Tested-by: Alexander Holler hol...@ahsoftware.de
Acked-by: Alexander Holler
OPP pointer is RCU protected, hence after finding it, de-reference
also should be protected with the same RCU context else the OPP
pointer may become invalid.
Reported-by: Jack Mitchell j...@embed.me.uk
Tested-by: Alexander Holler hol...@ahsoftware.de
Tested-by: Jack Mitchell j...@embed.me.uk
OPP pointers cannot be expected to be valid beyond the boundary
of rcu_read_lock and rcu_read_unlock. Unfortunately, the current
exynos4 busfreq driver does not honor the usage constraint and stores
the OPP pointer in struct busfreq_data. This could potentially
become invalid later such as: across
OPP pointers are protected by RCU locks, the pointer validity is
permissible only under the section of rcu_read_lock to rcu_read_unlock
Add documentation to the effect.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/devfreq/devfreq.c |5 +
1 file changed, 5 insertions(+)
diff
Cliff == Cliff Brake cliff.br...@gmail.com writes:
Hi,
Cliff I'm working with the 3.0 kernel on a 3730. It appears that when
Cliff I set a GPIO to output and set it high in the bootloader, this
Cliff gets reset when the kernel starts. Is this expected, and is
Cliff there any workaround to
* Ezequiel Garcia elezegar...@gmail.com [130118 11:43]:
Tony,
On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren t...@atomide.com wrote:
* Daniel Mack zon...@gmail.com [130114 15:30]:
On Jan 15, 2013 2:06 AM, Tony Lindgren t...@atomide.com wrote:
* Ezequiel Garcia elezegar...@gmail.com
On Fri, Jan 18, 2013 at 6:11 PM, Tony Lindgren t...@atomide.com wrote:
* Ezequiel Garcia elezegar...@gmail.com [130118 11:43]:
Tony,
On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren t...@atomide.com wrote:
* Daniel Mack zon...@gmail.com [130114 15:30]:
On Jan 15, 2013 2:06 AM, Tony Lindgren
On Friday, January 18, 2013 01:52:31 PM Nishanth Menon wrote:
Hi,
Despite being documented in function documentation and in
Documentation/power/opp.txt, many of the users of OPP APIs
dont honor RCU lock usage appropriately.
This recently appeared in IRC discussion earlier today [1].
I did
89 matches
Mail list logo
