On 09/07/2012 06:04 PM, Russell King - ARM Linux wrote:
> On Fri, Sep 07, 2012 at 05:34:35PM -0600, Stephen Warren wrote:
>> I guess it's a pretty basic premise of the current PCI code that all the
>> PCI scanning happens well before any device drivers are registered,
>> which in turn means that de
On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote:
> When called with a non-zero of_node, fill out a new ramoops_platform_data
> with data from the specified Flattened Device Tree node.
> Update ramoops documentation with the new FDT interface.
> Update devicetree/binding documentation wi
On Wed, Sep 05, 2012 at 05:06:04PM +0530, Sourav Poddar wrote:
> +static struct regmap_config smsc_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = SMSC_MAX_REGISTER - 1;
That max_register setup looks very odd...
> + .cac
Kukjin Kim wrote:
>
> Sachin Kamat wrote:
> >
> > Commit: f447ed8b31d (gpio: samsung: add flags specifier to
> > device-tree binding) adds a flag to represent active low state
> > for gpio line. Since gpio-keys on Origen board are active low,
> > using this flag to represent the same.
> >
> > Sign
Sachin Kamat wrote:
>
> Adds heartbeat gpio-leds support to Origen board.
>
> Signed-off-by: Sachin Kamat
> ---
> arch/arm/boot/dts/exynos4210-origen.dts |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
> b/arch/arm/bo
Sachin Kamat wrote:
>
> Commit: f447ed8b31d (gpio: samsung: add flags specifier to
> device-tree binding) adds a flag to represent active low state
> for gpio line. Since gpio-keys on Origen board are active low,
> using this flag to represent the same.
>
> Signed-off-by: Sachin Kamat
> Reviewed
On 09/07/12 15:58, David Brown wrote:
> On Wed, Sep 05, 2012 at 12:28:58PM -0700, Stephen Boyd wrote:
>
>> +DT_MACHINE_START(MSM8960_DT, "Qualcomm MSM (Flattened Device Tree)")
> The description string should specify the general name of what this is
> suspporting. Right now, with these patches, it
On Fri, Sep 07, 2012 at 05:34:35PM -0600, Stephen Warren wrote:
> I guess it's a pretty basic premise of the current PCI code that all the
> PCI scanning happens well before any device drivers are registered,
> which in turn means that device_add() doesn't trigger the device's
> probe() until much
On 08/14/2012 05:51 PM, Stephen Warren wrote:
> On 08/14/2012 04:58 PM, Stephen Warren wrote:
>> On 08/14/2012 03:55 PM, Bjorn Helgaas wrote:
>>> On Tue, Aug 14, 2012 at 12:58 PM, Thierry Reding
>>> wrote:
On Tue, Aug 14, 2012 at 01:39:23PM -0600, Stephen Warren wrote:
> On 08/13/2012 05:
On Wed, Sep 05, 2012 at 12:28:58PM -0700, Stephen Boyd wrote:
> +DT_MACHINE_START(MSM8960_DT, "Qualcomm MSM (Flattened Device Tree)")
The description string should specify the general name of what this is
suspporting. Right now, with these patches, it would list
Qualcomm MSM (Flattened Device
* Peter Ujfalusi [120905 04:59]:
> +
> + ocp {
> + mcbsp1: mcbsp@48074000 {
> + compatible = "ti,omap2420-mcbsp";
> + reg = <0x48074000 0xff>;
> + reg-names = "mpu";
> + interrupts = <59>, /* TX interru
On Fri, Sep 07, 2012 at 10:57:01AM -0400, Jason Cooper wrote:
> On Mon, Sep 03, 2012 at 06:58:07PM +0200, Andrew Lunn wrote:
> > Tools like kisskb are good at finding build regressions in the kernel
> > sources. However, regressions in the DT desscriptions are not found,
> > because generally these
On Fri, Sep 7, 2012 at 6:35 PM, Tony Lindgren wrote:
> In the pure GPIO pins only case it could be all done in the GPIO controller,
> but it's probably best to have the pins muxed by the drivers using them.
Yes, that's an easier way to say the long unreadable thing I just
posted ...
> Some driv
On Fri, Sep 7, 2012 at 6:00 PM, Domenico Andreoli wrote:
> On Fri, Sep 07, 2012 at 02:30:59PM +, AnilKumar, Chimata wrote:
>> How can gpio driver knows that leds-gpio driver require
>> these 4 pins?
>
> because leds-gpio requests each gpio (specified in the DT against a specific
> gpio contro
* Linus Walleij [120907 14:40]:
> On Thu, Sep 6, 2012 at 7:45 PM, Tony Lindgren wrote:
>
> >> > The warning should be pinctrl related as the pinctrl drivers may not be
> >> > device tree based drivers.
> >>
> >> Exactly my concern. Also the warning shouldnt be present on systems where
> >> pinct
On Thu, Sep 6, 2012 at 7:45 PM, Tony Lindgren wrote:
>> > The warning should be pinctrl related as the pinctrl drivers may not be
>> > device tree based drivers.
>>
>> Exactly my concern. Also the warning shouldnt be present on systems where
>> pinctrl is disabled.
>
> But pinctrl_get_select() re
On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch wrote:
> Adopt pinctrl support to leds-gpio driver based on leds-gpio
> device pointer, pinctrl driver configure SoC pins to GPIO
> mode according to definitions provided in .dts file.
>
> Signed-off-by: AnilKumar Ch
Looks good from a pinctrl point
> diff --git a/arch/arm/mach-kirkwood/board-dnskw.c
> b/arch/arm/mach-kirkwood/board-dnskw.c
> index 4ab3506..e202a07 100644
> --- a/arch/arm/mach-kirkwood/board-dnskw.c
> +++ b/arch/arm/mach-kirkwood/board-dnskw.c
> @@ -67,29 +67,6 @@ static unsigned int dnskw_mpp_config[] __initdata = {
>
On 09/07/2012 03:56 PM, Tony Lindgren wrote:
> * Jon Hunter [120907 13:27]:
>> Hi Tony,
>>
>> On 08/30/2012 03:14 PM, Tony Lindgren wrote:
>>> * Jon Hunter [120816 08:05]:
On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
>
> Did we get conclude on this? I haven't got anything further
On Fri, Sep 07, 2012 at 10:57:01AM -0400, Jason Cooper wrote:
> On Mon, Sep 03, 2012 at 06:58:07PM +0200, Andrew Lunn wrote:
> > Tools like kisskb are good at finding build regressions in the kernel
> > sources. However, regressions in the DT desscriptions are not found,
> > because generally these
* Jon Hunter [120907 13:27]:
> Hi Tony,
>
> On 08/30/2012 03:14 PM, Tony Lindgren wrote:
> > * Jon Hunter [120816 08:05]:
> >> On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
> >>>
> >>> Did we get conclude on this? I haven't got anything further on this
> >>> thread, this may block baseport sup
Hi Tony,
On 08/30/2012 03:14 PM, Tony Lindgren wrote:
> * Jon Hunter [120816 08:05]:
>> On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
>>>
>>> Did we get conclude on this? I haven't got anything further on this
>>> thread, this may block baseport support for the new devices in omap2
>>> family,
On Fri, Sep 07, 2012 at 23:17:37, Cousson, Benoit wrote:
> Hi Vaibhav,
>
> The following patch is hacing some checkpatch issues.
>
> CHECK: Alignment should match open parenthesis
> #169: FILE: arch/arm/plat-omap/omap_device.c:591:
> + dev_dbg(&pdev->dev, "%s(): resources alr
Hi Vaibhav,
The following patch is having some checkpatch issues.
CHECK: Alignment should match open parenthesis
#169: FILE: arch/arm/plat-omap/omap_device.c:591:
+ dev_dbg(&pdev->dev, "%s(): resources already allocated
%d\n",
+ __func__
Hi Vaibhav,
The following patch is hacing some checkpatch issues.
CHECK: Alignment should match open parenthesis
#169: FILE: arch/arm/plat-omap/omap_device.c:591:
+ dev_dbg(&pdev->dev, "%s(): resources already allocated
%d\n",
+ __func
On 09/07/2012 07:23 PM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Sep 07, 2012 at 05:25:24PM +0200, Benoit Cousson wrote:
>> Thanks to Vaibhav omap_device fix
>> (ARM: OMAP: omap_device: Fix up resource names when booted with devicetre),
>> we can now specify reg and interrupts using standard device
Hi Florian,
I've just noticed that this patch is reporting some CHECK issues.
d1f5052 - gpio/twl4030: get platform data from device tree
CHECK: Alignment should match open parenthesis
#66: FILE: drivers/gpio/gpio-twl4030.c:412:
+ of_property_read_u32(dev->of_node, "ti,debounce",
+
* Felipe Balbi [120907 10:30]:
> Hi,
>
> On Fri, Sep 07, 2012 at 10:06:22AM -0700, Tony Lindgren wrote:
> > * Benoit Cousson [120907 08:26]:
> > > Thanks to Vaibhav omap_device fix
> > > (ARM: OMAP: omap_device: Fix up resource names when booted with
> > > devicetre),
> > > we can now specify
Hi,
On Fri, Sep 07, 2012 at 05:25:24PM +0200, Benoit Cousson wrote:
> Thanks to Vaibhav omap_device fix
> (ARM: OMAP: omap_device: Fix up resource names when booted with devicetre),
> we can now specify reg and interrupts using standard device tree
> attributes.
>
> Update the OMAP4 dtsi file wi
d more appropriate. However you are right
>> >> that it is useful to always have it available, so I'm fine with removing
>> >> the annotations altogether. Do you want me to follow up with a patch? Or
>> >> can you just take the first version? I'm no
* Benoit Cousson [120907 08:26]:
> Thanks to Vaibhav omap_device fix
> (ARM: OMAP: omap_device: Fix up resource names when booted with devicetre),
> we can now specify reg and interrupts using standard device tree
> attributes.
>
> Update the OMAP4 dtsi file with missing reg and interrupts attri
* Benoit Cousson [120907 01:38]:
> Hi Anil,
>
> On 09/07/2012 07:30 AM, AnilKumar, Chimata wrote:
> > On Thu, Sep 06, 2012 at 15:08:21, AnilKumar, Chimata wrote:
> >> Add pinctrl and d_can device tree data to AM33XX family of devices.
> >> First two patches add support for pinctrl DT data and thi
you want me to follow up with a patch? Or
> >> can you just take the first version? I'm not sure if it still applies.
> >
> > You're right about how __devinit works. It's just that I don't think
> > hotplug is actually relevant here. We're tryin
* Koen Kooi [120907 01:46]:
>
> Op 6 sep. 2012, om 11:38 heeft AnilKumar Ch het volgende
> geschreven:
>
> > Adds GPIO pinctrl nodes to am3358_pinmux master node to control
> > user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
> >
> > [k...@dominion.thruhere.net: led0, led1 suggest
* AnilKumar Ch [120906 02:39]:
> Adds basic pinctrl device tree data for AM33XX family of devices.
> This patch is based on the pinctrl-single driver.
>
> Signed-off-by: AnilKumar Ch
Assuming Benoit will queue this series:
Acked-by: Tony Lindgren
> ---
> arch/arm/boot/dts/am33xx.dtsi |9
Allow a gpio-fan to be defined in devicetree, see binding documentation
for details.
Signed-off-by: Jamie Lentin
---
.../devicetree/bindings/gpio/gpio-fan.txt | 25 +
drivers/hwmon/gpio-fan.c | 111
2 files changed, 136 insertions(+)
This is an attempt at getting DT support into gpio-fan, in a similar
fashion to gpio-leds and gpio-keys. I guess the most contentious bit is
going to be the bindings.
Tested on a D-Link DNS-320.
Feedback appreciated!
Jamie Lentin (2):
hwmon: Add devicetree bindings to gpio-fan
ARM: kirkwood:
Remove more board-specific code by using devicetree to define the fan
attached to both boards.
Signed-off-by: Jamie Lentin
---
arch/arm/boot/dts/kirkwood-dnskw.dtsi | 10 ++
arch/arm/mach-kirkwood/board-dnskw.c | 25 -
2 files changed, 10 insertions(+), 25 de
On 09/06/2012 08:58 PM, Shawn Guo wrote:
> On Thu, Sep 06, 2012 at 04:35:25PM -0600, Stephen Warren wrote:
>> I believe this patch is causing issues initializing PCI-Express on Tegra.
>>
>> In next-20120906, I cold-booted 10 times. 3 times, PCIe initialized OK,
>> and 7 times, the driver timed out
On 09/07/2012 03:08 AM, Heiko Stübner wrote:
> Am Freitag, 7. September 2012, 10:04:24 schrieb Alex Courbot:
>>> For your power_seq_run function you write that it simply returns an error
>>> code on failure and looking through it I also just found the error return
>>> statement. This would leave a
* Domenico Andreoli [120907 09:01]:
>
> So is this the preferred way to attach gpio users to gpio provides in DT
> whenever gpios are muxed?
>
> I would well see these info hidden in the gpio controller so, at least
> for gpios, no magic numbers would be required in the DT (except the gpio
> num
On 09/07/2012 11:24 AM, Stephen Warren wrote:
> On 08/15/2012 02:06 PM, Thierry Reding wrote:
>> On Tue, Jul 31, 2012 at 03:18:43PM -0500, Rob Herring wrote:
>>> On 07/26/2012 02:55 PM, Thierry Reding wrote:
When a bus specifies #address-cells > 2, of_bus_default_map()
now assumes that th
On 08/15/2012 02:06 PM, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 03:18:43PM -0500, Rob Herring wrote:
>> On 07/26/2012 02:55 PM, Thierry Reding wrote:
>>> When a bus specifies #address-cells > 2, of_bus_default_map()
>>> now assumes that the mapping isn't for a physical address but
>>> rathe
available, so I'm fine with removing
>> the annotations altogether. Do you want me to follow up with a patch? Or
>> can you just take the first version? I'm not sure if it still applies.
>
> You're right about how __devinit works. It's just that I don't th
On 7 September 2012 16:21, Seungwon Jeon wrote:
> On Friday, September 07, 2012, Thomas Abraham
> wrote:
>> Hi Seungwon,
>>
>> Thanks for reviewing the patch.
>>
>> On 5 September 2012 16:13, Seungwon Jeon wrote:
>> > On Wednesday, September 05, 2012, Thomas Abraham
>> > wrote:
>> > Version 6
On Fri, Sep 07, 2012 at 02:30:59PM +, AnilKumar, Chimata wrote:
> On Fri, Sep 07, 2012 at 16:32:51, Domenico Andreoli wrote:
> > On Fri, Sep 07, 2012 at 09:10:50AM +, AnilKumar, Chimata wrote:
> > > On Fri, Sep 07, 2012 at 14:18:39, Domenico Andreoli wrote:
> > > > On Sat, Sep 1, 2012 at 10
Hi Tony,
On 09/06/2012 08:58 PM, Tony Lindgren wrote:
> The extra serial port is not available on 34xx. And the current
> omap3-beagle.dts file is for omap3-beagle-xm.dts as it lists 512MB
> of memory.
Indeed, my Beagle is in fact a xM :-)
It is too bad that we do have to duplicate the DTS file
Thanks to Vaibhav omap_device fix
(ARM: OMAP: omap_device: Fix up resource names when booted with devicetre),
we can now specify reg and interrupts using standard device tree
attributes.
Update the OMAP4 dtsi file with missing reg and interrupts attributes.
Signed-off-by: Benoit Cousson
Cc: San
On Mon, Sep 03, 2012 at 06:58:07PM +0200, Andrew Lunn wrote:
> Tools like kisskb are good at finding build regressions in the kernel
> sources. However, regressions in the DT desscriptions are not found,
> because generally these build systems don't build the DT binary blobs.
>
> Extend the ARM al
On Fri, Sep 07, 2012 at 16:32:51, Domenico Andreoli wrote:
> On Fri, Sep 07, 2012 at 09:10:50AM +, AnilKumar, Chimata wrote:
> > Hi Domenico,
>
> Hi,
>
> > On Fri, Sep 07, 2012 at 14:18:39, Domenico Andreoli wrote:
> > > On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch wrote:
> > > > Adopt pinc
On 09/07/2012 03:27 PM, Fabio Porcedda :
> Don't fail the initialization check for the platform_data
> if there is avaiable an associated device tree node.
>
> Signed-off-by: Fabio Porcedda
Acked-by: Nicolas Ferre
Thanks, bye,
> ---
> drivers/usb/gadget/at91_udc.c | 2 +-
> 1 file changed, 1
Hi Dmitry,
On 09/06/2012 07:19 PM, Dmitry Torokhov wrote:
> In patch 6 you added a stub for of_find_node_by_name(), so do you really
> need this #ifdef?
True. I'll resend the series since I left the #ifdef also in other patch.
> Otherwise it looks good.
>
> Acked-by: Dmitry Torokhov
Thank you
Don't fail the initialization check for the platform_data
if there is avaiable an associated device tree node.
Signed-off-by: Fabio Porcedda
---
drivers/usb/gadget/at91_udc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at
On Fri, Sep 07, 2012 at 09:10:50AM +, AnilKumar, Chimata wrote:
> Hi Domenico,
Hi,
> On Fri, Sep 07, 2012 at 14:18:39, Domenico Andreoli wrote:
> > On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch wrote:
> > > Adopt pinctrl support to leds-gpio driver based on leds-gpio
> > > device pointer, pi
Add device nodes for the four instances of dw_mmc controllers in Exynos5250
and enable instance 0 and 2 for the smdk5250 board.
Signed-off-by: Thomas Abraham
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 57 +
arch/arm/boot/dts/exynos5250.dtsi | 32 +
Samsung Exynos SoC's extend the dw-mshc controller for additional clock and bus
control. Add support for these extensions and include provide device tree based
discovery suppory as well.
Signed-off-by: Thomas Abraham
Acked-by: Will Newton
---
.../devicetree/bindings/mmc/exynos-dw-mshc.txt |
The core dw-mshc controller driver can let platform specific implementations
of the dw-mshc controller to control the hardware as required by such
implementations. This is acheived by invoking implementation specific (optional)
callbacks. Define the list of callbacks supported the add invocation po
Some platforms allow for clock gating and control of bus interface unit clock
and card interface unit clock. Add support for clock lookup of optional biu
and ciu clocks for clock gating and clock speed determination.
Signed-off-by: Abhilash Kesavan
Signed-off-by: Thomas Abraham
Acked-by: Will Ne
Hi Domenico,
On Fri, Sep 07, 2012 at 14:18:39, Domenico Andreoli wrote:
> On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch wrote:
> > Adopt pinctrl support to leds-gpio driver based on leds-gpio
> > device pointer, pinctrl driver configure SoC pins to GPIO
> > mode according to definitions provided
Am Freitag, 7. September 2012, 10:04:24 schrieb Alex Courbot:
> > For your power_seq_run function you write that it simply returns an error
> > code on failure and looking through it I also just found the error return
> > statement. This would leave a device half turned on.
> >
> > So I'm wonderin
On 09/06/2012 10:51 PM, Tony Lindgren wrote:
> * Benoit Cousson [120905 07:42]:
>> Hi Florian,
>>
>> On 09/05/2012 09:46 AM, Florian Vaussard wrote:
>>> Hello,
>>>
>>> A number of platform data are missing when using twl4030/gpio from a
>>> device tree. This patchset adds the missing properties, u
Add the support for D6 and D7 LEDs on Beagle board.
- D6 will be used for heartbeat
- D7 will be used for mmc0
Signed-off-by: Benoit Cousson
---
It is based on top of the LEDB support added by Florian.
Regards,
Benoit
arch/arm/boot/dts/omap3-beagle.dts | 12
1 files changed, 12
On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch wrote:
> Adopt pinctrl support to leds-gpio driver based on leds-gpio
> device pointer, pinctrl driver configure SoC pins to GPIO
> mode according to definitions provided in .dts file.
Shouldn't be the interaction with the pinctrl layer left to gpioli
Op 6 sep. 2012, om 11:38 heeft AnilKumar Ch het volgende
geschreven:
> Adds GPIO pinctrl nodes to am3358_pinmux master node to control
> user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
>
> [k...@dominion.thruhere.net: led0, led1 suggested by koen]
> Signed-off-by: AnilKumar Ch
A
Hi Anil,
On 09/07/2012 07:45 AM, AnilKumar, Chimata wrote:
> On Wed, Sep 05, 2012 at 20:11:11, Hiremath, Vaibhav wrote:
>> On Wed, Sep 05, 2012 at 19:01:55, Cousson, Benoit wrote:
>>> Hi Vaibhav,
>>>
>>> On 09/05/2012 11:15 AM, Hiremath, Vaibhav wrote:
On Wed, Sep 05, 2012 at 13:53:58, Ujfalu
Hi Anil,
On 09/07/2012 07:30 AM, AnilKumar, Chimata wrote:
> On Thu, Sep 06, 2012 at 15:08:21, AnilKumar, Chimata wrote:
>> Add pinctrl and d_can device tree data to AM33XX family of devices.
>> First two patches add support for pinctrl DT data and third one
>> adds dcan DT data.
>>
>> Reason behi
On Friday 07 September 2012 16:29:03 Mark Brown wrote:
> On Fri, Sep 07, 2012 at 05:28:17PM +0900, Alex Courbot wrote:
> > We could make power sequences an option of its own and add #ifdefs to
> > drivers that use it to lift this ambiguity, but I like the transparency
> > of the current way. It als
On Fri, Sep 07, 2012 at 05:28:17PM +0900, Alex Courbot wrote:
> We could make power sequences an option of its own and add #ifdefs to drivers
> that use it to lift this ambiguity, but I like the transparency of the
> current
> way. It also seems hard (illegal?) to get rid of the legacy DT inter
On Thursday 06 September 2012 01:25:27 Stephen Warren wrote:
> On 08/31/2012 05:34 AM, Alexandre Courbot wrote:
> > Make use of the power sequences specified in the device tree or platform
> > data to control how the backlight is powered on and off.
> >
> > +++ b/Documentation/devicetree/bindings/
Dear AnilKumar, Chimata,
> On Fri, Sep 07, 2012 at 05:39:35, Marek Vasut wrote:
> > Dear Tony Lindgren,
> >
> > > * Marek Vasut [120905 19:05]:
> > > > Hi Tony,
> > > >
> > > > > * Marek Vasut [120904 20:13]:
> > > > > > Dear Bryan Wu,
> > > > > >
> > > > > > > On Sat, Sep 1, 2012 at 4:16 PM,
Hi Stephen,
Skipping the typos and rephrasing issues (which will all be addressed,
thanks!), these issues caught my attention more particularly:
On Thursday 06 September 2012 01:19:45 Stephen Warren wrote:
> > +"regulator" type required properties:
> > + - id: name of the regulator to use. Regu
On Fri, Sep 07, 2012 at 05:04:24PM +0900, Alex Courbot wrote:
> If e.g. the power on sequence fails at step N (of M steps for that sequence),
> one could try playing the corresponding power off sequence (either completely
> of from step M - N), but then again we cannot rely on sequences to be
>
On Thu, Sep 6, 2012 at 8:58 PM, Tony Lindgren wrote:
> Add pinctrl driver entries for omap2+. These all use
> the generic pinctrl-single driver for the padconf
> registers.
>
> Note that as 2420 and 2430 have different padmux
> registers, we now need to include omap2420.dtsi from
> omap2420-h4.dt
Hi Heiko,
On Thursday 06 September 2012 22:14:53 Heiko Stübner wrote:
> Hi Alexander,
>
> Am Freitag, 31. August 2012, 13:34:03 schrieb Alexandre Courbot:
> > Some device drivers (panel backlights especially) need to follow precise
> > sequences for powering on and off, involving gpios, regulator
On Fri, Sep 07, 2012 at 05:39:35, Marek Vasut wrote:
> Dear Tony Lindgren,
>
> > * Marek Vasut [120905 19:05]:
> > > Hi Tony,
> > >
> > > > * Marek Vasut [120904 20:13]:
> > > > > Dear Bryan Wu,
> > > > >
> > > > > > On Sat, Sep 1, 2012 at 4:16 PM, AnilKumar Ch
> > > > > > wrote:
> > > > > >
On Fri, 2012-09-07 at 14:45 +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> The dereference should be moved below the NULL test.
>
> spatch with a semantic match is used to found this.
> (http://coccinelle.lip6.fr/)
I haven't applied this patch yet (there was a similar one recently from
anoth
Am Freitag, 7. September 2012, 07:38:52 schrieb Kukjin Kim:
> Heiko Stübner wrote:
> > Until now the Exynos-SoC was the only Samsung-SoC supporting the GPIOs
> > via the device tree. This patch implements dt-support for the
> > s3c24xx arches.
> >
> > The controllers contain only 3 cells, as the u
Hi Seungwon,
Thanks for reviewing the patch.
On 5 September 2012 16:13, Seungwon Jeon wrote:
> On Wednesday, September 05, 2012, Thomas Abraham
> wrote:
> Version 6 is right?
>
>> Samsung Exynos SoC's extend the dw-mshc controller for additional clock and
>> bus
>> control. Add support for th
78 matches
Mail list logo
