From: Sylwester Nawrocki
Use the generic PHY API instead of the platform callback to control
the MIPI CSIS DPHY. The 'phy_label' field is added to the platform
data structure to allow PHY lookup on non-dt platforms
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
Acked-by: Felipe
From: Jingoo Han
Exynos Display Port can be used only for Exynos SoCs. In addition,
non-DT for EXYNOS SoCs is not supported from v3.11; thus, there is
no need to support non-DT for Exynos Display Port.
The 'include/video/exynos_dp.h' file has been used for non-DT
support and the content of file
From: Jingoo Han
Add a PHY provider driver for the Samsung Exynos SoC Display Port PHY.
Signed-off-by: Jingoo Han
Reviewed-by: Tomasz Figa
Cc: Sylwester Nawrocki
Acked-by: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
---
.../devicetree/bindings/phy/samsung-phy.txt|8 ++
d
From: Jingoo Han
Use the generic PHY API to control the DP PHY.
Signed-off-by: Jingoo Han
Reviewed-by: Tomasz Figa
Signed-off-by: Kishon Vijay Abraham I
---
.../devicetree/bindings/video/exynos_dp.txt | 18 +-
drivers/video/exynos/exynos_dp_core.c|
From: Sylwester Nawrocki
Generic PHY drivers are used to handle the MIPI CSIS and MIPI DSIM
DPHYs so we can remove now unused code at arch/arm/plat-samsung.
In case there is any board file for S5PV210 platforms using MIPI
CSIS/DSIM (not any upstream currently) it should use the generic
PHY API to
Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Felipe Balbi
Reviewed-by: Sylwester Nawrocki
---
drivers/usb/phy/phy-omap-usb2.c | 25 -
1 file chan
From: Sylwester Nawrocki
Use the generic PHY API instead of the platform callback to control
the MIPI DSIM DPHY. The 'phy_label' field is added to the platform
data structure to allow PHY lookup on non-dt platforms.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
Acked-by: Felip
Now that twl4030-usb is adapted to the new generic PHY framework,
*set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Felipe Balbi
Reviewed-by: Sylwester Nawrocki
---
drivers/usb/phy/phy-twl4030-usb.c | 57 +
From: Sylwester Nawrocki
Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2
receiver and MIPI DSI transmitter DPHYs.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
Acked-by: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
---
.../devicetree/bindings/phy/s
Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
and usb_phy_set_suspend is replaced with power_on and
power_off to align with the new PHY framework.
musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state mach
In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy device name) should be added in the platform
data of the controller.
Signed-off-by: Kishon Vijay Abraham I
Reviewed-by: Sylwester Nawrocki
Acked-by: Felipe Balbi
---
arch/arm/mach-omap2/usb-musb.c |
Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.
The PHY binding information can be found at
Documentation/devicetree/bindings/phy/phy-bindings
Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle.
This framework will be of use only to devices that uses external PHY (PHY
functionality is not embedded w
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.
PHY drivers should create the PHY by
Used the generic PHY framework API to create the PHY. Now the power off and
power on are done in omap_usb_power_off and omap_usb_power_on respectively.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break
Used the generic PHY framework API to create the PHY. For powering on
and powering off the PHY, power_on and power_off ops are used. Once the
MUSB OMAP glue is adapted to the new framework, the suspend and resume
ops of usb phy library will be removed.
However using the old usb phy library cannot
On 07/17/2013 03:30 PM, Grygorii Strashko wrote:
> On 07/17/2013 02:57 PM, Roger Quadros wrote:
>> Hi Grygorii,
>>
>> On 07/17/2013 02:41 PM, Grygorii Strashko wrote:
>>> Hi Tony, Kevin
>>>
>>> This patch series introduces dynamic pinctrl handling in OMAP device
>>> framework
>>> in the same way a
On Thursday 18 July 2013 11:54 AM, Greg KH wrote:
> On Thu, Jul 18, 2013 at 11:33:17AM +0530, Kishon Vijay Abraham I wrote:
Wanted to group all the PHY drivers to be used by different subsystems
(SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments
in my
ini
On Thu, Jul 18, 2013 at 11:33:17AM +0530, Kishon Vijay Abraham I wrote:
> >> Wanted to group all the PHY drivers to be used by different subsystems
> >> (SATA/USB/PCIE/HDMI/VIDEO) into a single entity. There were some comments
> >> in my
> >> initial version [3] on using a bus_type instead of clas
Hi,
On Wednesday 17 July 2013 10:55 PM, Greg KH wrote:
> On Wed, Jul 17, 2013 at 03:02:59PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 17 July 2013 11:59 AM, Greg KH wrote:
>>> On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
+menuconfig GENERIC_PHY
Hi Stephen,
On Monday 15 July 2013 12:40:29 Stephen Warren wrote:
> From: Stephen Warren
>
> This property is no longer required by the GPIO binding. Remove it.
>
> Signed-off-by: Stephen Warren
> Acked-by: Viresh Kumar
> ---
> This should presumably be applied along with the previous changes
Hi Luciano,
On Monday 01 July 2013 15:39:30 Luciano Coelho wrote:
> On Fri, 2013-06-28 at 16:21 +0300, Luciano Coelho wrote:
> > On Fri, 2013-06-28 at 15:18 +0300, Felipe Balbi wrote:
> > > On Fri, Jun 28, 2013 at 03:13:52PM +0300, Luciano Coelho wrote:
> > > > On Fri, 2013-06-28 at 14:41 +0300, F
Replace the numerical polarity flags with the PWM_POLARITY_INVERTED
symbolic constant.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/am335x-evmsk.dts | 3 ++-
arch/arm/boot/dts/wm8850-w70v2.dts | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am33
Don't redefine a PWM_SPEC_POLARITY macro with a value identical to
PWM_POLARITY_INVERTED, use the PWM DT macro directly.
Signed-off-by: Laurent Pinchart
---
drivers/pwm/core.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index
The PWM client cells format is documented in the generic pwm.txt
documentation and duplicated in all PWM driver bindings. Remove
duplicate information and reference pwm.txt instead.
Signed-off-by: Laurent Pinchart
---
Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | 8 +++-
Do
Define a PWM_POLARITY_INVERTED macro in include/dt-bindings/pwm/pwm.h to
be used by device tree sources.
Signed-off-by: Laurent Pinchart
---
Documentation/devicetree/bindings/pwm/pwm.txt | 7 ---
include/dt-bindings/pwm/pwm.h | 14 ++
2 files changed, 18 insertio
Hello,
Here's a small patch set that replaces PWM polarity numerical constants with
macros in DT.
The series is the result of splitting the original patch into four patches
that
- add the flag macro (both in a header file and in the PWM DT binding core
documentation)
- use the macro in the PWM
On Wed, Jul 17, 2013 at 06:22:46PM -0400, Nicolas Pitre wrote:
> On Wed, 17 Jul 2013, Samuel Ortiz wrote:
>
> > On Wed, Jul 17, 2013 at 02:29:02PM -0400, Nicolas Pitre wrote:
> > > At this point I don't really care about the name. I just want the damn
> > > thing merged upstream. But after seve
On 07/17/2013 03:38 PM, Pavel Machek wrote:
> On Wed 2013-07-17 10:57:08, Stephen Warren wrote:
>> On 07/16/2013 09:02 PM, Shawn Guo wrote:
>>> On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
Registering the driver earlier won't cause any bugs. However, it's not
the correc
On Wed, 17 Jul 2013, Samuel Ortiz wrote:
> On Wed, Jul 17, 2013 at 02:29:02PM -0400, Nicolas Pitre wrote:
> > At this point I don't really care about the name. I just want the damn
> > thing merged upstream. But after several iterations to either fit one
> > or another maintainers taste, each
On Wed, Jul 17, 2013 at 11:17:19AM -0400, Eduardo Valentin wrote:
> Hello all,
>
> As you noticed, I am working in a way to represent thermal data
> using device tree [1]. Essentially, this should be a way to say
> what to do with a sensor and how to associate (cooling) actions
> with it.
>
Seems
Hi Nicolas,
On Wed, Jul 17, 2013 at 02:29:02PM -0400, Nicolas Pitre wrote:
> On Wed, 17 Jul 2013, Russell King - ARM Linux wrote:
>
> > On Wed, Jul 17, 2013 at 11:57:55AM -0400, Nicolas Pitre wrote:
> > > The sanest location at this point might simply be
> > > drivers/platform/vexpress_spc.c or
Hi Pawel,
On Wed, Jul 17, 2013 at 03:20:11PM +0100, Pawel Moll wrote:
> On Wed, 2013-07-17 at 15:16 +0100, Nicolas Pitre wrote:
> > On Wed, 17 Jul 2013, Pawel Moll wrote:
> >
> > > On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote:
> > > > If this is really miscelaneous code that really does
Hi Lorenzo,
On Tue, Jul 16, 2013 at 05:05:42PM +0100, Lorenzo Pieralisi wrote:
> Hello,
>
> version v5 of VExpress SPC driver, please read on the changelog for major
> changes and explanations.
>
> The probing scheme is unchanged, since after trying the early platform
> devices approach it appea
Oleksandr Kozaruk wrote:
>Hello Jonathan,
>
> >Two very quick comments based on quick glance as it may be a while
>before I can do a full review.
>
> >We still have channels that are only usable for temperature being
>output to user space as voltage channels? Is the conversion so very
>hard?
>
On Wed, 17 Jul 2013, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 11:57:55AM -0400, Nicolas Pitre wrote:
> > The sanest location at this point might simply be
> > drivers/platform/vexpress_spc.c or drivers/platform/vexpress/spc.c
> > depending on whether or not more such driver glue
On Wed, Jul 17, 2013 at 11:11:19AM -0600, Stephen Warren wrote:
> On 07/17/2013 05:00 AM, Laurent Pinchart wrote:
> > On Monday 15 July 2013 21:39:31 Stephen Warren wrote:
> ...
> >> But then there's a problem where people assume that the common flags are
> >> always available, and somewhere they a
On 07/17/2013 01:12 PM, Oleksandr Kozaruk wrote:
> The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC,
> known also as Phoenix and PhoenixLite.
>
> The TWL6030 and TWL6032 have GPADC with 17 and 19 channels
> respectively. Some channels have current source and are used for
> measu
the
mean time, here is my work in progress. I'm still reading and
learning, so please don't do any detailed reviews yet :)
http://dev.laptop.org/~dsd/20130717/0001-dove-clk-dt-wip.patch
It includes the previous clock selection patch as this stuff is quite
closely bound with DT suppor
On Wed, Jul 17, 2013 at 03:02:59PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Wednesday 17 July 2013 11:59 AM, Greg KH wrote:
> > On Wed, Jun 26, 2013 at 05:17:29PM +0530, Kishon Vijay Abraham I wrote:
> >> +menuconfig GENERIC_PHY
> >> + tristate "PHY Subsystem"
> >> + help
> >> +Gene
Hi Sylwester,
Thanks for the quick review.
On Wed, Jul 17, 2013 at 10:09 PM, Sylwester Nawrocki
wrote:
> On 07/17/2013 06:20 PM, Prabhakar Lad wrote:
>> From: "Lad, Prabhakar"
>>
>> add OF support for the tvp7002 driver.
>>
>> Signed-off-by: Lad, Prabhakar
>> ---
>> This patch depends on http
On Wed, Jul 17, 2013 at 06:34:48PM +0300, Dan Carpenter wrote:
> In xilinx_spi_probe() we use xspi->irq to store negative error codes so
> it has to be signed. We weren't going to use the upper bit any way so
> this is fine.
Applied, thanks.
signature.asc
Description: Digital signature
On 07/17/2013 05:00 AM, Laurent Pinchart wrote:
> On Monday 15 July 2013 21:39:31 Stephen Warren wrote:
...
>> But then there's a problem where people assume that the common flags are
>> always available, and somewhere they aren't... Care is needed in the
>> choice of which common flags to define a
On Wed, Jul 17, 2013 at 11:57:55AM -0400, Nicolas Pitre wrote:
> The sanest location at this point might simply be
> drivers/platform/vexpress_spc.c or drivers/platform/vexpress/spc.c
> depending on whether or not more such driver glue is expected in the
> vexpress future. No point putting "arm
On 07/16/2013 09:02 PM, Shawn Guo wrote:
> On Tue, Jul 16, 2013 at 09:45:43AM -0600, Stephen Warren wrote:
>> Registering the driver earlier won't cause any bugs. However, it's not
>> the correct approach.
>>
>> Deferred probe /is/ the approach for assuring correct dependencies
>> between drivers.
On Wed, Jul 17, 2013 at 04:26:28PM +0200, Gerhard Sittig wrote:
> On Wed, Jul 17, 2013 at 13:07 +0100, Mark Brown wrote:
> > This is a pretty long e-mail. It'd probably have taken less time to
> > fix the issues than to reply to the e-mail... but anyway.
> Not quite. Please consider that caref
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX b
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX b
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX b
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX b
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, currently we use the Palmas regulator names which is used for
different purposes on uEVM. Document the same based on 750-2628-XXX
boards -
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX b
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX b
Due to wrong older revision of documentation used as reference, we
seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This
series is based power tree on production board 750-2628-XXX platform.
Unfortunately, the wrong voltages may be detrimental to OMAP5 as they
supply hardware blocks a
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX b
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX b
On 07/17/2013 06:20 PM, Prabhakar Lad wrote:
> From: "Lad, Prabhakar"
>
> add OF support for the tvp7002 driver.
>
> Signed-off-by: Lad, Prabhakar
> ---
> This patch depends on https://patchwork.kernel.org/patch/2828800/
>
> Changes for v3:
> 1: Fixed review comments pointed by Sylwester.
Hi Sylwester,
On Wed, Jul 17, 2013 at 9:50 PM, Sylwester Nawrocki
wrote:
> On 07/17/2013 05:47 PM, Prabhakar Lad wrote:
>> From: "Lad, Prabhakar"
>>
>> This patch adds 'sync-on-green-active' property as part
>> of endpoint property.
>>
>> Signed-off-by: Lad, Prabhakar
>
> Thanks Prabhakar, it l
From: "Lad, Prabhakar"
add OF support for the tvp7002 driver.
Signed-off-by: Lad, Prabhakar
---
This patch depends on https://patchwork.kernel.org/patch/2828800/
Changes for v3:
1: Fixed review comments pointed by Sylwester.
.../devicetree/bindings/media/i2c/tvp7002.txt | 43
On 07/17/2013 05:47 PM, Prabhakar Lad wrote:
> From: "Lad, Prabhakar"
>
> This patch adds 'sync-on-green-active' property as part
> of endpoint property.
>
> Signed-off-by: Lad, Prabhakar
Thanks Prabhakar, it looks good to me.
Just a side note, the 'From' tag above isn't needed. It wasn't
adde
On Wed, 17 Jul 2013, Pawel Moll wrote:
> On Wed, 2013-07-17 at 15:16 +0100, Nicolas Pitre wrote:
> > On Wed, 17 Jul 2013, Pawel Moll wrote:
> >
> > > On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote:
> > > > If this is really miscelaneous code that really doesn't fit
> > > > anywhere else,
On Wed, Jul 17, 2013 at 03:26:38PM +0300, Dan Carpenter wrote:
> "xspi->irq" is unsigned int so it's never less than zero. I have added
> a cast.
Why is this better than changing irq to a signed type?
signature.asc
Description: Digital signature
___
d
From: "Lad, Prabhakar"
This patch adds 'sync-on-green-active' property as part
of endpoint property.
Signed-off-by: Lad, Prabhakar
---
Changes for v5:
1: Changed description for sync-on-green-active property in
documentation file as suggested by Sylwester.
Changes for v4:
1: Fix
On 07/17/2013 06:26 AM, Dan Carpenter wrote:
> "xspi->irq" is unsigned int so it's never less than zero. I have added
> a cast.
Um. Doesn't this just hide a warning, not solve the problem? If the
value can't be negative, so the if condition never fires, then the cast
won't change that...
* Grygorii Strashko [130717 04:49]:
> The pinctrl support in Device core assumed to be optional - so, It's
> valid case, when there are no definition for default device's pinctrl
> states in DT at all ("default", "active", "idle", "sleep").
> And in this case dev->pins == NULL and pinctrl_pm_selec
On 17/07/13 15:50, Rob Herring wrote:
> On 07/17/2013 09:06 AM, sudeep.karkadanage...@arm.com wrote:
>> From: Sudeep KarkadaNagesha
>>
>> Currently different drivers requiring to access cpu device node are
>> parsing the device tree themselves. Since the ordering in the DT need
>> not match the lo
* Grygorii Strashko [130717 04:49]:
> Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod
> framework. After switching to DT-boot the pinctrl handling was dropped from
> hwmod framework and, as it was recommended, OMAP IP's drivers have to be
> updated
> to handle pinctrl
In xilinx_spi_probe() we use xspi->irq to store negative error codes so
it has to be signed. We weren't going to use the upper bit any way so
this is fine.
Signed-off-by: Dan Carpenter
---
v2: The first version introduced an ugly cast. Sorry for that.
diff --git a/drivers/spi/spi-xilinx.c b/d
On Wed, Jul 17, 2013 at 09:03:53AM -0600, Stephen Warren wrote:
> On 07/17/2013 06:26 AM, Dan Carpenter wrote:
> > "xspi->irq" is unsigned int so it's never less than zero. I have added
> > a cast.
>
> Um. Doesn't this just hide a warning, not solve the problem? If the
> value can't be negative,
* Grygorii Strashko [130717 04:49]:
> Add dynamic "active"/"idle" pin states for uart3/4 which will be applied
> when uart3/4 state is switched from active to idle and back by Runtime
> PM or during system suspend.
This is good for testing code, but should not be merged because
omap4 has the iopa
On 07/17/2013 04:33 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 17-07-2013 15:12, Oleksandr Kozaruk wrote:
>
>> GPADC is the general purpose ADC present on twl6030.
>> The dt data is interrupt used to trigger end of ADC
>> conversion.
>
>> Signed-off-by: Oleksandr Kozaruk
>> ---
>> arch/arm/bo
On 07/17/2013 03:45 PM, Oleksandr Kozaruk wrote:
> On Mon, Jul 15, 2013 at 01:33:53PM +0200, Lars-Peter Clausen wrote:
>> On 07/15/2013 01:09 PM, Kozaruk, Oleksandr wrote:
>> [...]
>> >
>> >>> + ret = devm_request_threaded_irq(dev, irq, NULL,
>> >>> + twl6030_gpadc_irq_handler,
>> >>> + IRQF_ON
On Wed, Jul 17, 2013 at 03:06:20PM +0100, sudeep.karkadanage...@arm.com wrote:
> From: Sudeep KarkadaNagesha
>
> Now that the cpu device registration initialises the of_node(if available)
> appropriately for all the cpus, parsing here is redundant.
>
> This patch removes all DT parsing and uses
On 07/17/2013 09:06 AM, sudeep.karkadanage...@arm.com wrote:
> From: Sudeep KarkadaNagesha
>
> Currently different drivers requiring to access cpu device node are
> parsing the device tree themselves. Since the ordering in the DT need
> not match the logical cpu ordering, the parsing logic needs
From: "Mathieu J. Poirier"
Adding a simple device tree binding for the specification of key sequences.
Definition of the keys found in the sequence are located in
'include/uapi/linux/input.h'.
For the sysrq driver, holding the sequence of keys down for a specific amount
of time
will reset the s
On Wed, 17 Jul 2013, sudeep.karkadanage...@arm.com wrote:
> From: Sudeep KarkadaNagesha
>
> Currently different drivers requiring to access cpu device node are
> parsing the device tree themselves. Since the ordering in the DT need
> not match the logical cpu ordering, the parsing logic needs to
On Wed, Jul 17, 2013 at 13:07 +0100, Mark Brown wrote:
>
> On Wed, Jul 17, 2013 at 01:22:29PM +0200, Gerhard Sittig wrote:
> > On Mon, Jul 15, 2013 at 21:17 +0100, Mark Brown wrote:
> > > On Mon, Jul 15, 2013 at 08:47:30PM +0200, Gerhard Sittig wrote:
>
> > > > sprintf(name, "psc%d_mclk", maste
On Wed, 2013-07-17 at 15:16 +0100, Nicolas Pitre wrote:
> On Wed, 17 Jul 2013, Pawel Moll wrote:
>
> > On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote:
> > > If this is really miscelaneous code that really doesn't fit
> > > anywhere else, it should rather go into drivers/misc/ as a last re
From: Sudeep KarkadaNagesha
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu->of_node instead.
Acked-by: Shawn Guo
Acked-by: Viresh Kumar
Signed-off-by: Sudeep K
On Wed, 17 Jul 2013, Pawel Moll wrote:
> On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote:
> > If this is really miscelaneous code that really doesn't fit
> > anywhere else, it should rather go into drivers/misc/ as a last resort.
>
> Interestingly enough drivers/misc was my first choice f
"xspi->irq" is unsigned int so it's never less than zero. I have added
a cast.
Signed-off-by: Dan Carpenter
diff --git a/drivers/spi/spi-xilinx.c b/drivers/spi/spi-xilinx.c
index fea815c..e5201fb 100644
--- a/drivers/spi/spi-xilinx.c
+++ b/drivers/spi/spi-xilinx.c
@@ -442,7 +442,7 @@ static int
From: Sudeep KarkadaNagesha
Currently the topology code computes cpu capacity and stores it in
the list along with hwid(which is MPIDR) as it parses the CPU nodes
in the device tree. This is required as it needs to be mapped to the
logical CPU later.
Since the CPU device nodes can be retrieved i
From: Sudeep KarkadaNagesha
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes DT parsing and uses cpu->of_node instead.
Cc: Viresh Kumar
Cc: Benjamin Herrenschmidt
Signed-off-by: Sudeep Kark
From: Sudeep KarkadaNagesha
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu->of_node instead.
Acked-by: Viresh Kumar
Signed-off-by: Sudeep KarkadaNagesha
---
d
From: Sudeep KarkadaNagesha
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu->of_node instead.
Cc: Viresh Kumar
Cc: Dmitry Eremin-Solenikov
Signed-off-by: Sudeep
From: Sudeep KarkadaNagesha
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu->of_node instead.
Cc: Deepak Sikri
Acked-by: Viresh Kumar
Signed-off-by: Sudeep Kark
From: Sudeep KarkadaNagesha
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu->of_node instead.
Cc: Viresh Kumar
Cc: Benjamin Herrenschmidt
Signed-off-by: Sudeep
From: Sudeep KarkadaNagesha
Currently different drivers requiring to access cpu device node are
parsing the device tree themselves. Since the ordering in the DT need
not match the logical cpu ordering, the parsing logic needs to consider
that. However, this has resulted in lots of code duplicatio
From: Sudeep KarkadaNagesha
Since the CPU device nodes can be retrieved using arch_of_get_cpu_node,
we can use it to avoid parsing the cpus node searching the cpu nodes and
mapping to logical index.
This patch removes parsing DT for cpu nodes by using of_get_cpu_node.
Cc: Lorenzo Pieralisi
Sig
From: Sudeep KarkadaNagesha
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu->of_node instead.
Acked-by: Shawn Guo
Acked-by: Viresh Kumar
Signed-off-by: Sudeep K
From: Sudeep KarkadaNagesha
As more and more information is getting added into the cpu node, the number
of drivers needing to parse the device tree for CPU nodes are increasing.
Most of the time, the information needed from the cpu node is preferred
in the logical CPU order. Hence many drivers fi
From: Sudeep KarkadaNagesha
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu->of_node instead.
Cc: Andrew Lunn
Cc: Jason Cooper
Acked-by: Viresh Kumar
Signed-of
From: Sudeep KarkadaNagesha
Now that the cpu device registration initialises the of_node(if available)
appropriately for all the cpus, parsing here is redundant.
This patch removes all DT parsing and uses cpu->of_node instead.
Cc: Mark Langsdorf
Acked-by: Viresh Kumar
Signed-off-by: Sudeep Ka
From: Sudeep KarkadaNagesha
Currently set_secondary_cpus_clock assume the CPU logical ordering
and the MPDIR in DT are same, which is incorrect.
Since the CPU device nodes can be retrieved in the logical ordering
using the DT helper, we can remove the devices tree parsing.
This patch removes DT
From: Sudeep KarkadaNagesha
CPUs are also registered as devices but the of_node in these cpu
devices are not initialized. Currently different drivers requiring
to access cpu device node are parsing the nodes themselves and
initialising the of_node in cpu device.
The of_node in all the cpu device
From: Sudeep KarkadaNagesha
OF/DT core library now provides architecture specific hook to match the
logical cpu index with the corresponding physical identifier. Most of the
cpu DT node parsing and initialisation is contained in devtree.c. So it's
better to define ARM specific arch_match_cpu_phys
Arnd
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: 2013年7月15日 3:30
> To: Neil Zhang
> Cc: Jason Cooper; Matt Sealey; grant.lik...@linaro.org;
> haojian.zhu...@gmail.com; devicetree-discuss@lists.ozlabs.org;
> linux-ker...@vger.kernel.org; linux-arm-ker...@lists.
On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote:
> If this is really miscelaneous code that really doesn't fit
> anywhere else, it should rather go into drivers/misc/ as a last resort.
Interestingly enough drivers/misc was my first choice for all the
vexpress stuff, but it wasn't received
On Tue, Jul 16, 2013 at 11:31 PM, Wei Yongjun wrote:
> From: Wei Yongjun
>
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
>
> Signed-off-by: Wei Yongjun
Acked-by: Daniel Drake
___
On Wed, 17 Jul 2013, Pawel Moll wrote:
> On Tue, 2013-07-16 at 17:05 +0100, Lorenzo Pieralisi wrote:
> > /drivers/mfd is probably not the right place for this code as it stands (but
> > probably will be when the entire driver, with DVFS and config interface, is
> > complete).
>
> Not that it real
1 - 100 of 118 matches
Mail list logo
