Hi Sourav,
On Fri, Oct 05, 2012 at 12:56:26PM +0530, Sourav Poddar wrote:
> From: G, Manjunath Kondaiah
>
> SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
> supports a keypad scan matrix of 23*8.This driver uses this
> device as a keypad driver.
>
> Tested on omap5430 evm w
On Tue, Oct 23, 2012 at 1:58 PM, Mark Brown
wrote:
> One problem
> is that we don't have a home for the SoC integration so we're trying to
> shove it all into the drivers which just leads to a stack of pointless
> boilerplate when the driver isn't actually doing anything beyond the
> basic patter
On Wed, 2012-10-24 at 00:14 +0200, Thierry Reding wrote:
> On Tue, Oct 23, 2012 at 07:10:24AM +1300, Tony Prisk wrote:
> [...]
> > @@ -87,6 +98,11 @@ static int vt8500_pwm_enable(struct pwm_chip *chip,
> > struct pwm_device *pwm)
> > {
> > struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
>
On 10/23/2012 1:15 PM, Jon Hunter wrote:
> Hi Mitch,
>
> On 10/23/2012 11:55 AM, Mitch Bradley wrote:
>> On 10/23/2012 4:49 AM, Jon Hunter wrote:
>>
>>> Therefore, I believe it will improve search time and hence, boot time if
>>> we have interrupt-parent defined in each node.
>>
>> I strongly susp
Hi Mitch,
On 10/23/2012 11:55 AM, Mitch Bradley wrote:
> On 10/23/2012 4:49 AM, Jon Hunter wrote:
>
>> Therefore, I believe it will improve search time and hence, boot time if
>> we have interrupt-parent defined in each node.
>
> I strongly suspect (based on many years of performance tuning, wit
On Tue, Oct 23, 2012 at 07:10:24AM +1300, Tony Prisk wrote:
[...]
> @@ -87,6 +98,11 @@ static int vt8500_pwm_enable(struct pwm_chip *chip, struct
> pwm_device *pwm)
> {
> struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
>
> + if (!clk_enable(vt8500->clk)) {
> + dev_err(c
On 10/23/12 19:12, Arun Kumar K wrote:
Hi Seungwoo Kim,
Thank you for the review.
+
+ /* Reserve memory for MFC only if it's available */
+ mfc_mem.compatible = "samsung,mfc-v6";
+ if (of_scan_flat_dt(s5p_fdt_find_mfc_mem,&mfc_mem))
of_scan_flat_dt() is called but it does not hav
From: Stephen Warren
This binding is intended to represent the hardware reset signals present
internally in most IC (SoC, FPGA, ...) designs.
Such a binding would allow the creation of a "reset subsystem", which
could replace APIs such as the following Tegra-specific API:
void tegra_periph_rese
> "Andreas" == Andreas Larsson writes:
Andreas> The registers in the GRLIB port of the controller are 32-bit
Andreas> and in big endian byte order. The PRELOW and PREHIGH registers
Andreas> are merged into one register. The subsequent registers have
Andreas> their offset decreased accordi
> "Andreas" == Andreas Larsson writes:
Andreas> There are no platform resources of type IORESOURCE_IRQ on
Andreas> sparc, so the irq number is acquired in a different manner for
Andreas> sparc. The general case uses platform_get_irq, that internally
Andreas> still uses platform_get_resour
On 10/23/2012 02:33 PM, Alan Stern wrote:
> On Tue, 23 Oct 2012, Stephen Warren wrote:
>
>>> Nothing intrinsically distinguishes this class of hardware. The only
>>> thing these devices have in common is that they can be managed by
>>> Linux's ehci-platform driver.
>>
>> I don't agree. They're al
On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
> Hi Dimitry,
>
> On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> > Hi Sourav,
> >
> > On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
> >> Adapt keypad to use pinctrl framework.
> >>
> >> Tested on omap4430 sdp with
On Tue, 23 Oct 2012, Stephen Warren wrote:
> > Nothing intrinsically distinguishes this class of hardware. The only
> > thing these devices have in common is that they can be managed by
> > Linux's ehci-platform driver.
>
> I don't agree. They're all EHCI USB controllers (or all EHCI USB
> contr
On 10/23/2012 11:59 AM, Alan Stern wrote:
> On Tue, 23 Oct 2012, Stephen Warren wrote:
>
So, rather than:
compatible = "usb-ehci";
You should always have e.g.:
compatible = "nvidia,tegra20-ehci", "usb-ehci";
Given that, there is then always enough infor
On Tue, 23 Oct 2012, Stephen Warren wrote:
> >> So, rather than:
> >>
> >> compatible = "usb-ehci";
> >>
> >> You should always have e.g.:
> >>
> >> compatible = "nvidia,tegra20-ehci", "usb-ehci";
> >>
> >> Given that, there is then always enough information in the device tree
> >> for the driver
Hi,
(please don't top-post)
On Tue, Oct 23, 2012 at 07:51:22AM -1000, Mitch Bradley wrote:
> Perhaps I misunderstood what you were suggesting. I thought that, when
> you said "explicitly manage all their resources", you meant that the
> driver should know the platform-specific details about cloc
Perhaps I misunderstood what you were suggesting. I thought that, when
you said "explicitly manage all their resources", you meant that the
driver should know the platform-specific details about clocks and power
domains. That is one possible interpretation of the word "explicit".
Now I see that
HI,
On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote:
> On 10/23/2012 12:03 AM, Felipe Balbi wrote:
> > Hi,
> >
> > I much prefer having drivers explicitly manage all their resources,
> > which would mean that pinctrl calls need to be done on probe() and, if
> > necessary, during sus
On 10/23/2012 12:03 AM, Felipe Balbi wrote:
> Hi,
>
> I much prefer having drivers explicitly manage all their resources,
> which would mean that pinctrl calls need to be done on probe() and, if
> necessary, during suspend()/resume().
Per-driver resource management is certainly convenient when y
On 10/23/2012 4:49 AM, Jon Hunter wrote:
> Therefore, I believe it will improve search time and hence, boot time if
> we have interrupt-parent defined in each node.
I strongly suspect (based on many years of performance tuning, with
special focus on boot time) that the time difference will be com
Hi,
before I have a closer look I have some general questions, especially
about the heavy usage of SysFS for configuring the IP core module.
Generally, we are not allowed to use SysFS for CAN device configuration.
- Why may the user want to configure the resources on a per device base?
- Aren't
On 10/23/2012 08:10 AM, Alan Stern wrote:
> On Mon, 22 Oct 2012, Stephen Warren wrote:
>
>>> I see. But why would it be done this way instead having a separate
>>> property?
>>
>> Well, I did say normally:-)
>>
>> I can certainly see an argument for representing these differences using
>> custom
On 10/23/2012 05:59 PM, Jon Hunter wrote:
>
> On 10/23/2012 10:09 AM, Benoit Cousson wrote:
>> On 10/23/2012 04:49 PM, Jon Hunter wrote:
>>> Hi Seb,
>>>
>>> On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
Add base address and interrupt line inside Device Tree data for
OMAP5
Si
On 10/23/2012 10:09 AM, Benoit Cousson wrote:
> On 10/23/2012 04:49 PM, Jon Hunter wrote:
>> Hi Seb,
>>
>> On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
>>> Add base address and interrupt line inside Device Tree data for
>>> OMAP5
>>>
>>> Signed-off-by: Sebastien Guiriec
>>> ---
>>> arch/arm/
The registers in the GRLIB port of the controller are 32-bit and in big endian
byte order. The PRELOW and PREHIGH registers are merged into one register. The
subsequent registers have their offset decreased accordingly. Hence the register
access needs to be handled in a non-standard manner using cu
On sparc, irqs are not present as an IORESOURCE in the struct platform_device
representation. Therefore, for sparc the irq needs to be fetched in a different
manner.
The GRLIB port of the ocores i2c controller needs custom getreg and setreg
functions to allow for big endian register access and to
There are no platform resources of type IORESOURCE_IRQ on sparc, so the irq
number is acquired in a different manner for sparc. The general case uses
platform_get_irq, that internally still uses platform_get_resource.
Signed-off-by: Andreas Larsson
---
drivers/i2c/busses/i2c-ocores.c | 13
On 10/23/2012 04:49 PM, Jon Hunter wrote:
> Hi Seb,
>
> On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
>> Add base address and interrupt line inside Device Tree data for
>> OMAP5
>>
>> Signed-off-by: Sebastien Guiriec
>> ---
>> arch/arm/boot/dts/omap5.dtsi | 16
>> 1 file ch
Hi Seb,
On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
> Add base address and interrupt line inside Device Tree data for
> OMAP5
>
> Signed-off-by: Sebastien Guiriec
> ---
> arch/arm/boot/dts/omap5.dtsi | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boo
Arun Kumar K wrote:
>
> This patch adds device tree entry for MFC v6 in the Exynos5
> SoC. Makes the required changes in the clock files and adds
> MFC to the DT device list.
>
> Signed-off-by: Naveen Krishna Chatradhi
> Signed-off-by: Arun Kumar K
> ---
> .../devicetree/bindings/media/s5p-mfc
On Mon, 22 Oct 2012, Stephen Warren wrote:
> > I see. But why would it be done this way instead having a separate
> > property?
>
> Well, I did say normally:-)
>
> I can certainly see an argument for representing these differences using
> custom properties, rather than deriving the information
Rahul Sharma wrote:
>
> This patch set adds the DT based support for Samsung's Exynos5250. It adds
> device tree nodes for hdmi, mixer, hdmiphy and hdmiddc. The name of these
> devices are changed to the one matching with drivers. Exynos-drm and
> exynos
> hdmi-drm-commmon devices are removed from
Adding lkml. DT patches should go to both lists.
On 10/23/2012 05:30 AM, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla
>
> As part of of_platform_populate call, the existing code iterates each
> child node and then creates a platform device for each child, however
> there is bug in the
On 9/12/2012 10:05 PM, Sekhar Nori wrote:
> This series adds basic DT boot support for DA850 EVM and EnBW CMC board.
> It applies to master branch of Linux DaVinci tree[1].
>
> Resending this because I missed copying the DT and Documentation folks
> last time around. Sorry about that. There is no
On Tue, Oct 23, 2012 at 11:59:30AM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 11:37 AM, Mark Brown
> > On Tue, Oct 23, 2012 at 11:26:40AM +0200, Linus Walleij wrote:
> > Can we handle this with power domains - if different devices require
> > different orderings they can be placed in po
Hi,
On Tue, Oct 23, 2012 at 12:45:33PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi wrote:
> > On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
>
> >> So the biggest implementation of the notifier approach to resource
> >> handling is the SH clock th
On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi wrote:
> On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
>> So the biggest implementation of the notifier approach to resource
>> handling is the SH clock thing:
>> drivers/base/power/clock_ops.c
>
> that's different right ? It's just
Hi,
You will have to wait a few I prepare a patch series for pinctrl
so most of the current drivers will support pinctrl and requere it
this will availabe rc3 or rc4 max
then I will merge more update and boards
Best Regards,
J.
On 12:00 Tue 23 Oct , Fabio Po
Hi,
On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 12:23 PM, Thomas Petazzoni
> wrote:
> >
> > On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
> >
> >> > But it appears that shmobile prefer to get all resources using
> >> > bus notifiers.
> >> >
>
From: Srinivas Kandagatla
As part of of_platform_populate call, the existing code iterates each
child node and then creates a platform device for each child, however
there is bug in the code which does not check the match table before
creating the platform device. This might result creating two p
On Tue, Oct 23, 2012 at 12:23 PM, Thomas Petazzoni
wrote:
>
> On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
>
>> > But it appears that shmobile prefer to get all resources using
>> > bus notifiers.
>> >
>> > So we need to form some kind of consensus ... or live with
>> > the fact that di
Hi,
On Tue, Oct 23, 2012 at 12:04:01PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 11:35 AM, Benoit Cousson wrote:
> > On 10/23/2012 11:13 AM, Linus Walleij wrote:
>
> >> So Sourav, please tell us a bit about your plans for this
> >> and other drivers!
> >
> > Yeah, this idea is to han
On Mon, Oct 22, 2012 at 6:08 PM, Haojian Zhuang
wrote:
> Configure pins by pinctrl driver.
>
> Signed-off-by: Haojian Zhuang
So as I think the distributed approach to this is OK:
Acked-by: Linus Walleij
Yours,
Linus Walleij
___
devicetree-discuss ma
On Mon, Oct 22, 2012 at 6:08 PM, Haojian Zhuang
wrote:
> Configure pins by pinctrl driver.
>
> Signed-off-by: Haojian Zhuang
So as I think the distributed approach to this is OK:
Acked-by: Linus Walleij
Yours,
Linus Walleij
___
devicetree-discuss ma
On Mon, Oct 22, 2012 at 6:08 PM, Haojian Zhuang
wrote:
> Pinctrl driver is necessary for MMP DT & MMP2 DT platforms.
>
> Signed-off-by: Haojian Zhuang
Acked-by: Linus Walleij
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discus
On Tue, Oct 23, 2012 at 11:35 AM, Benoit Cousson wrote:
> On 10/23/2012 11:13 AM, Linus Walleij wrote:
>> So Sourav, please tell us a bit about your plans for this
>> and other drivers!
>
> Yeah, this idea is to handle pinctrl from all the drivers, and
> potentially change the mode during suspend
On Tue, Oct 23, 2012 at 11:37 AM, Mark Brown
wrote:
> On Tue, Oct 23, 2012 at 11:26:40AM +0200, Linus Walleij wrote:
>> I thought about that, but it does not allow us to control the
>> resource activation/deactivation order.
>
>> In some drivers the suspend() path could be:
>
>> - pins to sleep
>>
Signed-off-by: Fabio Porcedda
---
arch/arm/boot/dts/evk-pro3.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/evk-pro3.dts b/arch/arm/boot/dts/evk-pro3.dts
index ce959ee..96e50f5 100644
--- a/arch/arm/boot/dts/evk-pro3.dts
+++ b/arch/arm/boot/dts/evk-pro3.dts
@@ -
On Tue, Oct 23, 2012 at 10:31:28AM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 23, 2012 at 11:22:47AM +0200, Thierry Reding wrote:
> > On Tue, Oct 23, 2012 at 09:41:46PM +1300, Tony Prisk wrote:
> > > Further to the discussion, my preference is still for of_clk_get()
> > > (although I've c
On Tue, Oct 23, 2012 at 11:26:40AM +0200, Linus Walleij wrote:
> I thought about that, but it does not allow us to control the
> resource activation/deactivation order.
> In some drivers the suspend() path could be:
> - pins to sleep
> - clk_disable
> - disable external regulator
> - release pow
Hi Linus,
On 10/23/2012 11:13 AM, Linus Walleij wrote:
> On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
> wrote:
>> Hi Sourav,
>>
>> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>>> Adapt keypad to use pinctrl framework.
>>>
>>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>>
>
On Tue, Oct 23, 2012 at 11:22:47AM +0200, Thierry Reding wrote:
> On Tue, Oct 23, 2012 at 09:41:46PM +1300, Tony Prisk wrote:
> > Further to the discussion, my preference is still for of_clk_get()
> > (although I've changed the patch anyway as you saw because it makes no
> > difference in this case
On Mon, Oct 22, 2012 at 10:26 PM, Stephen Warren wrote:
> On 10/22/2012 02:45 AM, Linus Walleij wrote:
>> For the Ux500 drivers we have found that all of those that have pin
>> resources actually have to be handled by the driver. The reason is
>> that all of them have idle and/or sleep states tha
On Tue, Oct 23, 2012 at 09:41:46PM +1300, Tony Prisk wrote:
> On Mon, 2012-10-22 at 10:04 +0200, Thierry Reding wrote:
> > On Mon, Oct 22, 2012 at 08:36:22PM +1300, Tony Prisk wrote:
> > > On Mon, 2012-10-22 at 09:24 +0200, Thierry Reding wrote:
> > > > On Mon, Oct 22, 2012 at 08:09:07PM +1300, Ton
Hi Dimitry,
On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
> Hi Sourav,
>
> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>> Adapt keypad to use pinctrl framework.
>>
>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>
> I do not see anything in the driver that would directly use p
On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
wrote:
> Hi Sourav,
>
> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>> Adapt keypad to use pinctrl framework.
>>
>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>
> I do not see anything in the driver that would directly use pinctr
On Mon, 2012-10-22 at 10:04 +0200, Thierry Reding wrote:
> On Mon, Oct 22, 2012 at 08:36:22PM +1300, Tony Prisk wrote:
> > On Mon, 2012-10-22 at 09:24 +0200, Thierry Reding wrote:
> > > On Mon, Oct 22, 2012 at 08:09:07PM +1300, Tony Prisk wrote:
> > > > On Mon, 2012-10-22 at 19:51 +1300, Tony Prisk
57 matches
Mail list logo
