On 23.09.2013 23:20, Felipe Balbi wrote:
> On Sun, Sep 22, 2013 at 01:46:58PM +0200, Daniel Mack wrote:
>> -static struct dev_pm_ops am35x_pm_ops = {
>> -.suspend= am35x_suspend,
>> -.resume = am35x_resume,
>> -};
>> +static SIMPLE_DEV_PM_OPS(am35x_pm_ops, am35x_suspend, am
On Tuesday 24 September 2013 11:18 AM, Sourav Poddar wrote:
> On Tuesday 24 September 2013 11:14 AM, Sekhar Nori wrote:
>> On Tuesday 24 September 2013 11:09 AM, Sourav Poddar wrote:
>>> omap5 has all devices enable by default.
>>> Disable thosw not required in omap5 uevm board.
>> s/thosw/those
>>
On Tuesday 24 September 2013 11:14 AM, Sekhar Nori wrote:
On Tuesday 24 September 2013 11:09 AM, Sourav Poddar wrote:
omap5 has all devices enable by default.
Disable thosw not required in omap5 uevm board.
s/thosw/those
Fix the following:
Added status parameter
Simulataneously, fix some tab
On Tuesday 24 September 2013 11:09 AM, Sourav Poddar wrote:
> omap5 has all devices enable by default.
> Disable thosw not required in omap5 uevm board.
s/thosw/those
>
> Fix the following:
> Added status parameter
> Simulataneously, fix some tab formatting.
s/Simulataneously/Simultaneously
>
On 09/23/2013 10:15 PM, Linus Walleij wrote:
> On Sun, Sep 22, 2013 at 4:40 PM, Javier Martinez Canillas
> wrote:
>
>> To use a GPIO pin as an interrupt line, two previous configurations
>> have to be made:
>>
>> a) Map the GPIO pin as an interrupt line into the Linux irq space
>> b) Enable the G
omap5 has all devices enable by default.
Disable thosw not required in omap5 uevm board.
Fix the following:
Added status parameter
Simulataneously, fix some tab formatting.
Signed-off-by: Sourav Poddar
---
arch/arm/boot/dts/omap5-uevm.dts | 38 +++---
1 files c
On Mon, Sep 23, 2013 at 10:28 AM, Balaji T K wrote:
> On Saturday 21 September 2013 12:41 AM, Nishanth Menon wrote:
>>
>> 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
>>> ---
>>> arch/arm/boot/dts/
On 09/23/2013 06:59:17 PM, Pavel Machek wrote:
During 3.12-rc, Will Deacon introduced code into arch/arm that
requires binutils 2.22.
I'm sorry, it occurs to me I should have been more explicit:
HH! KILL IT WITH
FIRE!!!
Rob--
To unsubscr
On 09/23/2013 06:59:17 PM, Pavel Machek wrote:
During 3.12-rc, Will Deacon introduced code into arch/arm that
requires binutils 2.22.
Um, my toolchain is using the last gplv2 snapshot of binutils out of
git, which is just past 2.17 and can build armv7 (but not armv8).
Binutils 2.12->2.22 is
Hi!
> > Tony, if you did not have time for review this patch months ago
> > or you found it only today - no problem, I understand it. But
> > what I need to know is what will happen with board-rx51-* files
> > (and when?) You can see that DT does not have definitions of all
> > n900 hw parts (
Hi!
> > No, isp1704 is power supply driver and export data via power
> > supply (sysfs) interface. It is not regulator but charger driver.
>
> well it does not charge the battery directly, but just provides a
> power line with 5 Volt and a specified amount of current to the
> system, doesn't it?
During 3.12-rc, Will Deacon introduced code into arch/arm that
requires binutils 2.22.
Signed-off-by: Pavel Machek
---
Or that changes should be reverted. I have updated my buildsystem on main
machine, but ... it seems that debian-cross repository does not
contain new enough bintuil
Hi,
On Mon, Sep 23, 2013 at 02:35:35PM -0600, Stephen Warren wrote:
> On 09/15/2013 02:44 PM, Sebastian Reichel wrote:
> > Add SSI device tree data for OMAP34xx and Nokia N900.
>
> What is an "SSI" device, ...
Synchronous Serial Interface (SSI), which is an interface from
the OMAP3 for modem con
Hi!
> > > > Right. So Tony, will you accept future patches for board files?
> > >
> > > Only fixes to board-*.c files please unless there's a _really_
> > > good reason to make things more complex with the platform data.
> > > Let's not make the DT conversion any more complex than it
> > > alread
* Sebastian Reichel [130923 13:55]:
> On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Rohár wrote:
> > On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
> > > > It is not as simple as it looks. This is reason why I
> > >
Using the PaRAM configuration function that we split for reuse by the
different DMA types, we implement Cyclic DMA support.
For the cyclic case, we pass different configuration parameters to this
function, and handle all the Cyclic-specific functionality separately.
Callbacks to the DMA users are
The following series adds Cyclic DMA support to TI EDMA DMA Engine driver.
First we split out the calculations for the Slave DMA case into a separate
function so that we may reuse it for the calculations of Cyclic DMA parameters.
Next patch then adds the actual support for Cyclic DMA, enables inte
PaRAM set calculation is abstracted into its own function to
enable better reuse for other DMA cases such as cyclic. We adapt
the Slave SG case to use the new function.
This provides a much cleaner abstraction to the internals of the
PaRAM set. However, any PaRAM attributes that are not common to
davinci-pcm uses 16 as the no.of periods. With this, in EDMA we have to
allocate atleast 17 slots: 1 slot for channel, and 16 slots the periods.
Due to this, the MAX_NR_SG limitation causes problems, set it to 20 to make
cyclic DMA work when davinci-pcm is converted to use DMA Engine. Also add
a c
On 09/23/2013 01:32 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Aug 21, 2013 at 04:29:44PM +0300, Ivan T. Ivanov wrote:
>> From: "Ivan T. Ivanov"
>>
>> MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys (SNPS)
>> and HS, SS PHY's control and configuration registers.
>>
>> It could operate
The GPIO API defines 0 as being a valid GPIO number, so this field needs
to be initialized explicitly.
Signed-off-by: Thierry Reding
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-
To support a wider variety of backlight setups, introduce an optional
enable GPIO. Legacy users of the platform data already have a means of
supporting GPIOs by using the .init(), .exit() and .notify() hooks. DT
users however cannot use those, so an alternative method is required.
In order to ease
In preparation for adding an optional regulator and enable GPIO to the
driver, split the power on and power off sequences into separate
functions to reduce code duplication at the multiple call sites.
Signed-off-by: Thierry Reding
---
drivers/video/backlight/pwm_bl.c | 59 +++
The GPIO API defines 0 as being a valid GPIO number, so this field needs
to be initialized explicitly.
Signed-off-by: Thierry Reding
---
arch/unicore32/kernel/puv3-nb0916.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/unicore32/kernel/puv3-nb0916.c
b/arch/unicore32/kernel/puv3-nb091
The GPIO API defines 0 as being a valid GPIO number, so this field needs
to be initialized explicitly.
A special case is the Palm Tungsten|C board. Since it doesn't use any
quirks that would require the existing .init() or .exit() hooks it can
simply use the new enable_gpio field.
Signed-off-by:
Make use of the new enable_gpio field and allow it to be set from DT as
well. Now that all legacy users of platform data have been converted to
initialize this field to an invalid value, it is safe to use the field
from the driver.
Signed-off-by: Thierry Reding
---
.../bindings/video/backlight/p
The GPIO API defines 0 as being a valid GPIO number, so this field needs
to be initialized explicitly.
Signed-off-by: Thierry Reding
---
arch/arm/mach-shmobile/board-armadillo800eva.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c
b/arch/arm/m
The GPIO API defines 0 as being a valid GPIO number, so this field needs
to be initialized explicitly.
Signed-off-by: Thierry Reding
---
arch/arm/mach-s3c24xx/mach-h1940.c| 1 +
arch/arm/mach-s3c24xx/mach-rx1950.c | 1 +
arch/arm/mach-s3c64xx/mach-crag6410.c | 1 +
arch/arm/mach-s3c64xx/ma
Many backlights require a power supply to work properly. This commit
uses a power-supply regulator, if available, to power up and power down
the panel.
Signed-off-by: Thierry Reding
---
.../bindings/video/backlight/pwm-backlight.txt | 2 ++
drivers/video/backlight/pwm_bl.c
The default for backlight devices is to be enabled immediately when
registering with the backlight core. This can be useful for setups that
use a simple framebuffer device and where the backlight cannot otherwise
be hooked up to the panel.
However, when dealing with more complex setups, such as th
This series adds the ability to specify a GPIO and a power supply to
enable a backlight.
Patch 1 refactors the power on and power off sequences into separate
functions in preparation for subsequent patches.
Patch 2 adds an optional GPIO to enable a backlight. This patch only
includes the field wi
Hi,
On Sun, Sep 22, 2013 at 01:46:58PM +0200, Daniel Mack wrote:
> This makes am35x_pm_ops const.
>
> Also, checkpatch.pl complains about the use of DEV_PM_OPS:
>
> ERROR: Macros with complex values should be enclosed in parenthesis
>
> Signed-off-by: Daniel Mack
> ---
> drivers/usb/musb/am
On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Rohár wrote:
> On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
> > > It is not as simple as it looks. This is reason why I
> > > submited this patch long time after I submite
On 09/15/2013 02:44 PM, Sebastian Reichel wrote:
> Add SSI device tree data for OMAP34xx and Nokia N900.
What is an "SSI" device, ...
> diff --git a/Documentation/devicetree/bindings/hsi/omap_ssi.txt
> b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
... and what is the "HSI" subsystem?
>
On Sun, Sep 22, 2013 at 4:40 PM, Javier Martinez Canillas
wrote:
> To use a GPIO pin as an interrupt line, two previous configurations
> have to be made:
>
> a) Map the GPIO pin as an interrupt line into the Linux irq space
> b) Enable the GPIO bank and configure the GPIO direction as input
>
> M
On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
> > It is not as simple as it looks. This is reason why I
> > submited this patch long time after I submited bq2415x
> > driver.
> >
> > Problem is that for rx51 is needed sp
On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
> It is not as simple as it looks. This is reason why I submited
> this patch long time after I submited bq2415x driver.
>
> Problem is that for rx51 is needed specific function which connect
> to two drivers (bq2415x and isp1704) plus
On Mon, Aug 26, 2013 at 06:08:33PM +0300, Roger Quadros wrote:
> Split USB2 PHY and USB3 PHY into separate omap-control-usb
> nodes. Get rid of "ti,type" property.
>
> CC: Benoit Cousson
> Signed-off-by: Roger Quadros
Benoit ? ping here too...
--
balbi
signature.asc
Description: Digital sig
Hi,
On Mon, Aug 26, 2013 at 06:08:32PM +0300, Roger Quadros wrote:
> Split otghs_ctrl and USB2 PHY power down into separate
> omap-control-usb nodes. Get rid of "ti,type" property.
>
> Also get rid of "ti,has-mailbox" property from usb_otg_hs
> node and provide the ctrl-module phandle.
>
> CC: B
Hi,
On Wed, Aug 21, 2013 at 04:29:45PM +0300, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov"
>
> These drivers handles control and configuration of the HS
> and SS USB PHY transceivers. They are part of the driver
> which manage Synopsys DesignWare USB3 controller stack
> inside Qualcomm SoC's.
Hi,
On Wed, Aug 21, 2013 at 04:29:44PM +0300, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov"
>
> MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
> (SNPS) and HS, SS PHY's control and configuration registers.
>
> It could operate in device mode (SS, HS, FS) and host
> mode (SS, HS, FS
Hi,
On Tue, Aug 20, 2013 at 12:56:03PM +0300, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov"
>
> MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
> (SNPS) and HS, SS PHY's control and configuration registers.
>
> It could operate in device mode (SS, HS, FS) and host
> mode (SS, HS, FS
Hello,
On Monday 23 September 2013 20:03:00 you wrote:
> * Pali Rohár [130920 12:29]:
> > 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
Hi,
On Mon, Sep 23, 2013 at 10:38:43AM -0700, Tony Lindgren wrote:
> * Aaro Koskinen [130921 06:56]:
> > Without this the eMMC (root file system) cannot be used on N950/N9.
> > Any ideas for a proper solution?
> Can you please update this patch on the quirks series I posted
> few days ago?
Ok,
Hi Felipe,
There is an issue with this patch and is shown below.
I will send a v3 for this.
On 08/15/2013 01:18 PM, Roger Quadros wrote:
> Modelling the RESET line as a regulator supply wasn't a good idea
> as it kind of abuses the regulator framework and also makes adaptation
> code more complex
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
> On Thu, 19 Sep 2013, 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 s
Javier,
On Monday 23 September 2013 01:07 PM, Tony Lindgren wrote:
> * Javier Martinez Canillas [130923 10:09]:
>> On 09/23/2013 06:45 PM, Tony Lindgren wrote:
>>>
>>> Hmm does this still work for legacy platform data based
>>> drivers that are doing gpio_request() first?
>>>
>>
>> Yes it still w
On Sat, Sep 21, 2013 at 8:39 PM, Laurent Pinchart
wrote:
> Add DT bindings for the pcf857x-compatible chips and parse the device
> tree node in the driver.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../devicetree/bindings/gpio/gpio-pcf857x.txt | 71
> ++
> drivers/gp
* Pali Rohár [130920 12:29]:
> 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
* Aaro Koskinen [130921 06:56]:
> Without this the eMMC (root file system) cannot be used on N950/N9.
> Any ideas for a proper solution?
>
> Signed-off-by: Aaro Koskinen
> ---
> arch/arm/mach-omap2/board-generic.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/a
* Pavel Machek [130921 05:45]:
> Hi!
>
> > > > > > > --- /dev/null
> > > > > > > +++ b/arch/arm/mach-omap2/board-rx51-camera.c
> > > > >
> > > > > [...]
> > > > >
> > > > > > Ping, can you review this patch v2?
> > > > >
> > > > > I don't think Tony will accept any new board stuff for
> > > >
* Javier Martinez Canillas [130923 10:09]:
> On 09/23/2013 06:45 PM, Tony Lindgren wrote:
> >
> > Hmm does this still work for legacy platform data based
> > drivers that are doing gpio_request() first?
> >
>
> Yes it still work when booting using board files. I tested on my OMAP3 board
> and
On 09/23/2013 06:45 PM, Tony Lindgren wrote:
> * Javier Martinez Canillas [130922 07:49]:
>> --- a/drivers/gpio/gpio-omap.c
>> +++ b/drivers/gpio/gpio-omap.c
>> @@ -420,6 +420,29 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
>> int gpio,
>> return 0;
>> }
>>
>> +static void _
On 09/23/2013 06:14 PM, Stephen Warren wrote:
> On 09/22/2013 08:40 AM, Javier Martinez Canillas wrote:
>> To use a GPIO pin as an interrupt line, two previous configurations
>> have to be made:
>>
>> a) Map the GPIO pin as an interrupt line into the Linux irq space
>> b) Enable the GPIO bank and
* Javier Martinez Canillas [130922 07:49]:
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -420,6 +420,29 @@ static int _set_gpio_triggering(struct gpio_bank *bank,
> int gpio,
> return 0;
> }
>
> +static void _set_gpio_mode(struct gpio_bank *bank, unsigned offset)
On 09/22/2013 08:40 AM, Javier Martinez Canillas wrote:
> To use a GPIO pin as an interrupt line, two previous configurations
> have to be made:
>
> a) Map the GPIO pin as an interrupt line into the Linux irq space
> b) Enable the GPIO bank and configure the GPIO direction as input
>
> Most GPIO/
On Saturday 21 September 2013 12:41 AM, Nishanth Menon wrote:
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
---
arch/arm/boot/dts/am335x-bone-common.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions
On Mon, Sep 23, 2013 at 04:51:06PM +0200, Sebastian Andrzej Siewior wrote:
> On 09/23/2013 06:17 AM, Vinod Koul wrote:
> > Looks fine, Sebastian cna you test it pls
>
> Just noticed that you already applied some of them. I just got back
> after a few weeks of. Will review & test as soon as I get t
On 09/20/2013 05:45 PM, Felipe Balbi wrote:
>
> Acked-by: Felipe Balbi
>
Those four patches went already in, for instance:
commit 781f17983015dae33324e34d1bb831e715fa04d4
Author: Sebastian Andrzej Siewior
AuthorDate: Tue Aug 20 18:35:49 2013 +0200
Commit: Felipe Balbi
CommitDate: Tue
On 09/23/2013 06:17 AM, Vinod Koul wrote:
> Looks fine, Sebastian cna you test it pls
Just noticed that you already applied some of them. I just got back
after a few weeks of. Will review & test as soon as I get to it.
>
> ~Vinod
>
Sebastian
--
To unsubscribe from this list: send the line "uns
On Mon, Sep 23, 2013 at 06:10:30PM +0400, Sergei Shtylyov wrote:
> >Unless it's actually likely to cause inclusion loop, I think it's
> >better to include the header than adding explicit declarations.
>
>Apparently, tastes differ here. E.g. Greg KH would have also told
> Roger to use forward d
Hello.
On 09/23/2013 01:48 AM, Tejun Heo wrote:
@@ -37,6 +37,7 @@
#include
#include
+#include
struct phy;
should suffice.
Unless it's actually likely to cause inclusion loop, I think it's
better to include the header than adding explicit declarations.
Apparently, tastes
On 09/23/2013 03:59 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 23-09-2013 11:37, Roger Quadros wrote:
>
Not sure why you asked -- I'm not using this driver, neither I'm
>
>>> Well, you have better grip of what's going on in the embedded world
>>> than me. I'm mostly curious whether add
On Mon 23 September 2013 14:50:12 Pali Rohár wrote:
> Hi Tony,
>
> here is new version (v2) of patch which adding max_current values to rx51
> board data. According to joerg safe value for max_current is 100 (10 mA).
>
>
> RX-51: Add missing max_current to rx51_lp5523_led_config
>
> File driver
Hi Felipe,
On 09/18/2013 03:49 PM, Roger Quadros wrote:
> "usb_otg_ss_refclk960m" is an optional functional clock to the
> UBS_OTG_SS module. So manage it in the driver.
>
Just realized that "usb_otg_ss_refclk960m" is in fact functional clock to the
PHY and not USB_OTG_SS module. The name is mi
Hello.
On 23-09-2013 11:37, Roger Quadros wrote:
Not sure why you asked -- I'm not using this driver, neither I'm
Well, you have better grip of what's going on in the embedded world
than me. I'm mostly curious whether adding dependency on PHY is okay.
There is no hard dependency on p
Hello.
On 23-09-2013 1:51, Tejun Heo wrote:
Not sure why you asked -- I'm not using this driver, neither I'm
Well, you have better grip of what's going on in the embedded world
than me. I'm mostly curious whether adding dependency on PHY is okay.
This driver already supports option
Hi Tony,
here is new version (v2) of patch which adding max_current values to rx51 board
data.
According to joerg safe value for max_current is 100 (10 mA).
RX-51: Add missing max_current to rx51_lp5523_led_config
File drivers/leds/leds-lp55xx-common.c refuse to change led_current sysfs
attrib
On 20/09/2013 00:02, Russell King :
Signed-off-by: Russell King
---
drivers/usb/chipidea/ci_hdrc_imx.c |4 +---
drivers/usb/dwc3/dwc3-exynos.c |4 +---
drivers/usb/host/ehci-atmel.c |4 +---
For Atmel driver:
Acked-by: Nicolas Ferre
[..]
diff --git a/drivers/usb/ho
On 20/09/2013 00:01, Russell King :
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 t
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
> On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> > register_platform_device_full() can setup the DMA mask provided the
> > appropriate member is set in struct platform_device_info. So lets
> > make that be the case. This
On Sat, Sep 21, 2013 at 09:00:00PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
> > Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> > > The DMA API requires drivers to call the appropriate dma_set_mask()
> > > functions
On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> register_platform_device_full() can setup the DMA mask provided the
> appropriate member is set in struct platform_device_info. So lets
> make that be the case. This avoids a direct reference to the DMA
> masks by this driver.
>
> S
On Thu, Sep 19, 2013 at 10:48:01PM +0100, Russell King wrote:
> 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
Acked-by: Vinod Koul
~Vinod
> ---
>
On Sun, Sep 22, 2013 at 04:50:04PM +0200, Daniel Mack wrote:
> This patch adds support for suspend/resume functionality to the cppi41
> DMA driver. The steps necessary to make the system resume properly were
> figured out by trial-and-error. The code as it stands now is the
> minimum that has to be
On Mon, Sep 23, 2013 at 07:53:11AM +0200, Daniel Mack wrote:
> On 23.09.2013 06:09, Vinod Koul wrote:
> > On Sun, Sep 22, 2013 at 04:50:04PM +0200, Daniel Mack wrote:
>
> >> +#ifdef CONFIG_PM_SLEEP
> > a
> >
> >> +static int cppi41_suspend(struct device *dev)
> >> +{
> >> + struct cppi41_dd
On 09/22/2013 09:45 PM, Sergei Shtylyov wrote:
> On 09/20/2013 02:19 PM, Roger Quadros wrote:
>
From: Balaji T K
>
Add support for sata controller.
>
[Roger Q] Clean up.
>
CC: Benoit Cousson
Signed-off-by: Balaji T K
Signed-off-by: Roger Quadros
---
Hi,
On 09/22/2013 09:22 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 09/19/2013 05:05 PM, Roger Quadros wrote:
>
>> From: Balaji T K
>
>> Some platforms have a PHY hooked up to the
>> SATA controller. The PHY needs to be initialized
>> and powered up for SATA to work. We do that
>> using the PHY
Hi,
On 22/09/13 21:44, Peter Senna Tschudin wrote:
> Convert 0 to false and 1 to true when assigning values to bool
> variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
Tha
Hi Tejun,
On 09/23/2013 12:51 AM, Tejun Heo wrote:
> Hello,
>
> On Sun, Sep 22, 2013 at 10:24:36PM +0400, Sergei Shtylyov wrote:
>>Not sure why you asked -- I'm not using this driver, neither I'm
>
> Well, you have better grip of what's going on in the embedded world
> than me. I'm mostly c
80 matches
Mail list logo
