Benoit Cousson writes:
> In the case of DT, the PMIC and SR initialization will be done using
> a completely different mechanism.
>
> Disable this part if a DT blob is available.
>
> Signed-off-by: Benoit Cousson
> Cc: Kevin Hilman
Acked-by: Kevin Hilman
> ---
>
Benoit Cousson writes:
> Add initial DT support to retrieve the frequency using a
> DT attribute instead of the pdata pointer if of_node exist.
>
> Add documentation for omap i2c controller binding.
>
> Based on original patches from Manju and Grant.
>
> Signed-off-by: Benoit Cousson
> Cc: Ben D
Hi Benoit,
Benoit Cousson writes:
> Update pandaboard dts file with required clock frequencies
> for the i2c client devices existing on pandaboard.
>
> Add the twl6030 node in i2c1 controller.
>
> This is the minimal support needed to boot OMAP4 boards
> without any crash.
> The support for all
Greg, Alan,
Rajendra Nayak writes:
> v3 is rebased on top of the latest serial runtime
> patches[1] and boot tested with/without DT on OMAP4
> SDP and OMAP4 Panda boards.
With your ack on the drivers/tty/* stuff, I can queue this via the OMAP
tree on top of the runtime PM conversion that it dep
"Cousson, Benoit" writes:
> Hi Kevin,
>
> On 12/14/2011 6:06 AM, Kevin Hilman wrote:
>> Hi Benoit,
>>
>> Benoit Cousson writes:
>>
>>> Update pandaboard dts file with required clock frequencies
>>> for the i2c client devices
"Cousson, Benoit" writes:
> Hi Kevin,
>
> On 12/14/2011 2:06 AM, Kevin Hilman wrote:
>> Benoit Cousson writes:
>>
>>> Add initial DT support to retrieve the frequency using a
>>> DT attribute instead of the pdata pointer if of_node exist.
Richard Zhao writes:
> The driver get cpu operation point table from device tree cpu0 node,
Since we already have an existing OPP infrastructure in the kernel,
seems like this driver should get OPPs by asking the OPP layer.
This approach assumes the OPP layer is static at boot time and not
cha
Richard Zhao writes:
> On Wed, Jan 11, 2012 at 03:22:34PM -0800, Kevin Hilman wrote:
>> Richard Zhao writes:
>>
>> > The driver get cpu operation point table from device tree cpu0 node,
>>
>> Since we already have an existing OPP infrastructure in the kerne
Board code should not touch omap_device internals. To get the MPU/IVA devices,
use existing APIs: omap2_get_mpu_device(), omap2_get_iva_device().
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/board-omap3beagle.c | 23 ++-
1 files changed, 10 insertions(+), 13
that does the decoupling.
This will be necessary if we're going to decouple the platform_device
creation from the omap_device/omap_hwmod creation etc. This patch
leaves them both done in omap_device_build(), but shows that they can
be decoupled.
Kevin Hilman (7):
OMAP: omap_device: replac
The *_device_register() functions and the count/fill resources functions
are internal to omap_device and do not need to be in the header.
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/include/plat/omap_device.h |6 --
arch/arm/plat-omap/omap_device.c | 12
naming from the driver core.
Some pr_* prints were not converted with this patch since they are
used before the platform_device and struct device are created so
neither the dev_* prints or dev_name() is valid.
Reported-by: Russell King
Reviewed-by: Felipe Balbi
Signed-off-by: Kevin Hilman
Rather than embedding a struct platform_device inside a struct
omap_device, decouple them, leaving only a pointer to the
platform_device inside the omap_device.
This patch uses devres to allocate and attach the omap_device to the
struct device, so finding an omap_device from a struct device means
the platform_device pointer or struct device pointer, so fixing all
of the users was trivial.
This also makes it more difficult for device init code to directly
access members of struct omap_device, and allows for easier changing
of omap_device internals.
Cc: Paul Walmsley
Signed-off-by: Kevin
The internal device register functions do not need or use any omap_device
internals, so pass in a platform_device pointer instead of an omap_device
pointer.
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/omap_device.c | 22 +++---
1 files changed, 11 insertions(+), 11
from a struct device pointer.
Cc: Felipe Balbi
Signed-off-by: Kevin Hilman
---
Paul, please consider this minor cleanup for the v3.1 merge window.
Applies to v3.0-c6.
arch/arm/plat-omap/omap_device.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/arm
For converting from struct device to platform_device, and from
platform_device to struct device, there are existing macros. Use
them instead of manual use of container_of().
Signed-off-by: Kevin Hilman
---
arch/arm/plat-omap/mcbsp.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions
Grant Likely writes:
[...]
> The way I see it, you've got two options:
>
> 1) modify the of_platform_bus_create() to call some kind of
> of_platform_bus_create_omap() for devices that match "ti,omap3-device"
> or something.
>
> 2) Leave of_platform_bus_create(), and instead us a notifier to atta
Hi Sergei,
Sergei Shtylyov writes:
> On 22-07-2011 3:52, Kevin Hilman wrote:
>
>> For converting from struct device to platform_device, and from
>> platform_device to struct device,
>
>You mean from platform_device to omap_device?
>
Yes indeed, thanks. Updated
"G, Manjunath Kondaiah" writes:
> On Wed, Jul 27, 2011 at 02:45:33PM -0700, Hilman, Kevin wrote:
>> Hi Manjunath,
>>
>> On Wed, Jul 27, 2011 at 7:04 AM, G, Manjunath Kondaiah
>> wrote:
>> > Kevin,
>> >
>> > On Thu, Jul 21, 20
Russell King - ARM Linux writes:
> On Sat, Jul 30, 2011 at 08:58:07PM -0600, Grant Likely wrote:
>> On Sat, Jul 30, 2011 at 01:03:32PM +0100, Russell King - ARM Linux wrote:
>> > On Thu, Jul 21, 2011 at 04:52:18PM -0700, Kevin Hilman wrote:
>> > > Rather than embe
Russell King - ARM Linux writes:
> Help the typechecker do its job. As we have only one (at the moment...)
> And make it:
>
> +struct omap_device;
>
> struct pdev_archdata {
> +#ifdef CONFIG_ARCH_OMAP
> + struct omap_device *omap;
> +#endif
> };
>
> for bonus points, so we only get the add
Grant Likely writes:
> On Fri, Aug 12, 2011 at 9:09 AM, Cousson, Benoit wrote:
>> On 8/12/2011 4:35 PM, Arnd Bergmann wrote:
[...]
>>
>>> I think it's much easier to change the existing users of _byname over
>>> to fixed indexes than to come up with a new scheme that is better.
I disagree.
Arnd Bergmann writes:
> On Thursday 25 August 2011, Russell King - ARM Linux wrote:
>>
>> On Thu, Aug 25, 2011 at 02:16:14AM +0300, Felipe Balbi wrote:
>> > on top of all that, for IPs which are used on many SoCs (such as MUSB)
>> > it's quite silly to force all users to provide resources in a c
AnilKumar Ch writes:
> From: Colin Foe-Parker
>
> Set tps65217 PMIC status to OFF if power enable toggle is
> supported. Also adds platform data flag, which should be
> passed from board init data.
nit: changelog mentions platform_data, but the code is using DT.
Kevin
> Signed-off-by: Colin F
AnilKumar Ch writes:
> Enable system power off control for BeagleBone in am335x-bone.dts file
> under rtc node. RTC is the incharge of controlling the system power.
> This flag is used by the driver to hook up the pm_power_off system call.
>
> Signed-off-by: AnilKumar Ch
> ---
> arch/arm/boot/d
"Rafael J. Wysocki" writes:
> On Wednesday, July 25, 2012, Arnd Bergmann wrote:
>> On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
>> > On Tuesday, July 24, 2012, Arnd Bergmann wrote:
>> > > On Tuesday 24 July 2012, Rafael J. Wysocki wrote:
>> > > > On Tuesday, July 24, 2012, Arnd Bergmann wrot
Mark Brown writes:
> On Wed, Jul 25, 2012 at 05:38:35PM -0700, Kevin Hilman wrote:
>
>> That being said, I'm not sure why ti,hwmods is being used as an example
>> for powerdomains. hwmods describe the integration of SoC IP blocks
>> (base addr, IRQ, DMA channel etc.
ration code
>> together and out of the drivers. IME the SoCs where you need to do
>> different things for different IPs shoudl mostly still get some reuse
>> out of such an approach.
>
> Talking to Kevin Hilman today he was also stressing that
> power domains is a good thi
Linus Walleij writes:
> On Wed, Oct 31, 2012 at 9:10 PM, Kevin Hilman
> wrote:
>
>> Linus Walleij writes:
>
>
>>
>> > piece of hardware, this would be the right thing to do,
>> > and I think the in-kernel examples are all "simple",
On 11/02/2012 09:43 AM, Pantelis Antoniou wrote:
[...]
And then use the standard DT support to create later the platform_device that
does represent the new super-cape devices.
We know this is the ideal case. In fact that's the long term goal and we had
internal discussions about it.
Sinc
31 matches
Mail list logo
