On 03/20/2013 06:56 AM, Tomi Valkeinen wrote:
> On 2013-03-19 10:03, Alexandru Gheorghiu wrote:
>> Use PTR_RET function instead of IS_ERR and PTR_ERR.
>> Patch found using coccinelle.
>>
>> Signed-off-by: Alexandru Gheorghiu
>> ---
>> drivers/video/omap2/dss/core.c |5 +
>> 1 file change
On 03/20/2013 11:59 AM, Tomi Valkeinen wrote:
> On 2013-03-20 17:44, Jon Hunter wrote:
>>
>> On 03/20/2013 06:56 AM, Tomi Valkeinen wrote:
>>> On 2013-03-19 10:03, Alexandru Gheorghiu wrote:
>>>> Use PTR_RET function instead of IS_ERR and PTR_ER
On 03/20/2013 01:02 PM, Jon Hunter wrote:
>
> On 03/20/2013 11:59 AM, Tomi Valkeinen wrote:
>> On 2013-03-20 17:44, Jon Hunter wrote:
>>>
>>> On 03/20/2013 06:56 AM, Tomi Valkeinen wrote:
>>>> On 2013-03-19 10:03, Alexandru Gheorghiu wrote:
>&g
On 03/12/2013 06:05 AM, Russell King - ARM Linux wrote:
> On Tue, Mar 12, 2013 at 09:58:29AM +0200, Silviu-Mihai Popescu wrote:
>> This uses PTR_RET instead of IS_ERR and PTR_ERR in order to increase
>> readability.
>>
>> Signed-off-by: Silviu-Mihai Popescu
>> ---
>> arch/arm/mach-omap2/devices.
able "inuse" that is used
to determine if the device has been initialised and now use the
twl_priv structure instead. This is causing the kernel to panic on all
OMAP2+ devices, because we try to access the twl_priv->ready member
before checking if twl_priv is initialised. Fix this an
On 02/09/2013 08:52 PM, Tony Lindgren wrote:
> Hi,
>
> * Ruslan Bilovol [130208 11:41]:
>> The OMAP4 Blaze Tablet is TI OMAP4 processor-based
>> development platform in a tablet formfactor.
>> The platform contains many of the features found in
>> present-day handsets (such as audio, video, wire
On 02/08/2013 11:50 PM, Peter Ujfalusi wrote:
> On 02/08/2013 07:56 PM, Jon Hunter wrote:
>>> /**
>>> * twl_i2c_write - Writes a n bit register in TWL4030/TWL5030/TWL60X0
>>> * @mod_no: module number
>>> @@ -322,16 +323,17 @@ int twl_i2c_write(u8 m
On 02/12/2013 01:26 AM, Peter Ujfalusi wrote:
> On 02/11/2013 09:22 PM, Jon Hunter wrote:
>> Good point. I just noticed that none of my omap2+ board were booting and
>> on omap3/4 I was the panic in the twl code. I can't say that I checked
>> the panic on omap2, so may b
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
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
>>>
>>>
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 yea
Hi Gururaja,
On 10/17/2012 01:13 AM, Hebbar, Gururaja wrote:
> Hi,
>
> I came across a peculiar issue while updating GPIO debounce registers on
> OMAP platform.
>
> According to mainline commit ae547354a8ed59f19b57f7e1de9c7816edfc3537
>
> gpio/omap: save and restore debounce registers
>
> GPIO
Hi Gururaja,
On 10/18/2012 12:31 AM, Hebbar, Gururaja wrote:
> Jon,
>
> On Thu, Oct 18, 2012 at 02:42:01, Hunter, Jon wrote:
[snip]
>>> My doubt/questions are
>>> 1. Why should debounce registers be updated only when it's accessed
>>> previously?
>>
>> If debounce is not being used by any of t
On 12/21/2012 04:18 PM, Pratik Patel wrote:
> On Thu, Dec 20, 2012 at 04:54:38PM -0600, Jon Hunter wrote:
>>
>> On 12/20/2012 01:51 PM, Pratik Patel wrote:
>>> On Thu, Dec 20, 2012 at 11:46:13AM -0600, Jon Hunter wrote:
>>>>
>>>> On 12/19/20
On 12/19/2012 03:24 PM, Pratik Patel wrote:
[snip]
> Currently we use the CoreSight virtual bus to conveniently list
> sysfs configuration attributes for all the registered CoreSight
> devices.
>
> For eg:
> /sys/bus/coresight/devices/coresight-etm0/
> /sys/bus/coresight/devices/coresight-etm1/
On 12/20/2012 01:51 PM, Pratik Patel wrote:
> On Thu, Dec 20, 2012 at 11:46:13AM -0600, Jon Hunter wrote:
>>
>> On 12/19/2012 03:24 PM, Pratik Patel wrote:
>>
>> [snip]
>>
>>> Currently we use the CoreSight virtual bus to conveniently list
>>> sy
On 11/15/2012 11:07 AM, Igor Mazanov wrote:
> Remove inline from clock framework function definitions to
> build the kernel with GCC 4.7
Adding Mike to the party ...
May be good to add some details about the exact problem seen.
I am seeing the same problem today with GCC 4.7 and Tony's master
On 11/16/2012 03:36 AM, Arnd Bergmann wrote:
> On Thursday 15 November 2012, Lee Jones wrote:
>> On Thu, 15 Nov 2012, Arnd Bergmann wrote:
>>
>>> On Thursday 15 November 2012, Lee Jones wrote:
UARTs no longer require call-back information, since the reset
call-back was removed in 43b5f0d
On 04/17/2013 02:09 PM, Dan Murphy wrote:
> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
> are different.
>
> Abstract away the pinmux and the LED definitions for the two boards.
Just a heads-up but you should base this upon Benoit's for_3.10 branch
[1] as there is now
t; patch fixes it by always calling of_node_put().
>>
>> Signed-off-by: Lars-Peter Clausen
>
> Acked-by: Arnd Bergmann
Thanks! FWIW ...
Reviewed-by: Jon Hunter
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
On 04/19/2013 04:42 AM, Lars-Peter Clausen wrote:
> Currently the OF DMA code uses a spin lock to protect the of_dma_list from
> concurrent access and a per controller reference count to protect the
> controller
> from being freed while a request operation is in progress. If
> of_dma_controller_f
On 04/20/2013 05:38 AM, Arnd Bergmann wrote:
> On Saturday 20 April 2013, Lars-Peter Clausen wrote:
>> On 04/20/2013 12:45 AM, Jon Hunter wrote:
>>> I think that there is a problem here. For controllers using the
>>> of_dma_simple_xlate(), this will call dma_request_ch
On 04/19/2013 06:13 PM, Arnd Bergmann wrote:
> On Saturday 20 April 2013, Jon Hunter wrote:
>> Change also means that of_dma_request_slave_channel() cannot be called
>> from a context where it is not possible to sleep too, right? May be
>> worth mentioning this in the change
On 04/22/2013 03:33 AM, Lars-Peter Clausen wrote:
> Both of_dma_nbcells field of the of_dma_controller and the args_count field of
> the dma_spec are initialized by parsing the #dma-cells attribute of their
> device
> tree node. So if the device tree nodes of a DMA controller and the dma_spec
> m
On 04/22/2013 04:00 PM, Lars-Peter Clausen wrote:
> On 04/22/2013 10:52 PM, Jon Hunter wrote:
>>
>> On 04/22/2013 03:33 AM, Lars-Peter Clausen wrote:
>>> Both of_dma_nbcells field of the of_dma_controller and the args_count field
>>> of
>>> the dma_spec
On 28/05/13 23:05, Stephen Warren wrote:
> On 05/28/2013 03:25 PM, Jon Hunter wrote:
>>
>> On 27/05/13 15:37, Afzal Mohammed wrote:
>>> AM43x timer bindings.
>>>
>>> Signed-off-by: Afzal Mohammed
>>> ---
>>> Documentation/devicetr
On 03/22/2013 11:36 AM, Russell King - ARM Linux wrote:
> On Wed, Mar 20, 2013 at 01:28:47PM -0500, Jon Hunter wrote:
>> Sorry I am now not sure I follow you here. Someone just pointed out to
>> me that PTR_RET() is defined as ...
>>
>> static inline int __must_ch
imer.c
> @@ -220,7 +220,7 @@ static int __init omap_dm_timer_init_one(struct
> omap_dm_timer *timer,
>int posted)
> {
> char name[10]; /* 10 = sizeof("gptXX_Xck0") */
> - const char *oh_name;
> + const char *oh_name = NU
On 27/05/13 15:37, Afzal Mohammed wrote:
> AM43x 32K counter binding.
>
> Signed-off-by: Afzal Mohammed
> ---
> Documentation/devicetree/bindings/arm/omap/counter.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/counter.txt
> b/Documentat
On 27/05/13 15:37, Afzal Mohammed wrote:
> AM43x timer bindings.
>
> Signed-off-by: Afzal Mohammed
> ---
> Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
> b/Documentation/dev
;>
>>
>> Hi Matt,
>> Could you please drop this patch from the current series,
>> since this patch causes regression on omap3,4 platform
>> which are not yet dma dt adapted.
>> It is best to send this patch along with Jon Hunter dma dt series,
>> which add
On 02/13/2013 03:28 AM, Sourav Poddar wrote:
> Booting 3.8-rc6 on omap4 panda results in the following error
>
> [0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
> [0.445770] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz
> [0.473937] omap_i2c 48072000.i2c: did n
On 02/13/2013 09:57 AM, Jon Hunter wrote:
>
> On 02/13/2013 03:28 AM, Sourav Poddar wrote:
>> Booting 3.8-rc6 on omap4 panda results in the following error
>>
>> [0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
>> [0.445770] omap_i2c
On 02/13/2013 05:28 PM, Ruslan Bilovol wrote:
> Hi Tony, Jon,
>
> On Mon, Feb 11, 2013 at 9:00 PM, Tony Lindgren wrote:
>> * Jon Hunter [130211 10:58]:
>>>
>>> Please note that the blaze is derived from the omap4-sdp board and so I
>>> would hope th
Hi Neil,
On 12/12/2012 02:24 AM, NeilBrown wrote:
>
>
> This patch is based on an earlier patch by Grant Erickson
> which provided pwm devices using the 'legacy' interface.
>
> This driver instead uses the new framework interface.
>
> Cc: Grant Erickson
> Signed-off-by: NeilBrown
>
> diff -
On 12/12/2012 05:31 AM, Thierry Reding wrote:
> On Wed, Dec 12, 2012 at 07:24:30PM +1100, NeilBrown wrote:
[snip]
>> +static int omap_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
>> +{
>> +struct omap_chip *omap = to_omap_chip(chip);
>> +int status = 0;
>> +
>> +/* Enabl
On 12/12/2012 09:06 PM, NeilBrown wrote:
>
> [Thierry: question for you near the end - thanks]
>
> On Wed, 12 Dec 2012 10:08:28 -0600 Jon Hunter wrote:
>
>> Hi Neil,
>>
>> On 12/12/2012 02:24 AM, NeilBrown wrote:
>>>
>>>
>>> This pa
On 12/12/2012 10:33 PM, NeilBrown wrote:
> On Thu, 13 Dec 2012 14:06:35 +1100 NeilBrown wrote:
>
+ omap_dm_timer_enable(omap->dm_timer);
>>>
>>> Do you need to call omap_dm_timer_enable here? _set_load and _set_match
>>> will enable the timer. So this should not be necessary.
>>
>> True.
On 01/06/2013 03:12 PM, NeilBrown wrote:
[snip]
> I've been playing with off-mode and discovered that the first attempt to set
> the PWM after resume didn't work, but subsequent ones did.
> I did some digging and came up with the following patch.
> With this in place, the omap_pwm_suspend() ab
> continue;
> - }
>
> - if (property && !of_get_property(np, property, NULL)) {
> - of_node_put(np);
> + if (property && !of_get_property(np, property, NULL))
> continue;
> -
Now that the generic PM domain framework supports devices that require
multiple PM domains, update the device-tree binding for generic PM
domains to state that one or more PM domain is permitted for a device.
Signed-off-by: Jon Hunter
---
Documentation/devicetree/bindings/power/power_domain.txt
PM domain framework to allow a device to
define more than one PM domain in the device-tree 'power-domains'
property.
Jon Hunter (3):
PM / Domains: Add helper functions for finding and attaching PM
domains
PM / Domains: Add support for devices with multiple domains
dt-bindings
In preparation for supporting devices that require more than one PM
domain, move the code for finding and attaching PM domains into local
helper functions.
Signed-off-by: Jon Hunter
---
drivers/base/power/domain.c | 121 ++--
1 file changed, 73 insertions
.
For devices using device-tree, devices that require multiple PM domains
are detected by seeing if the 'power-domains' property has more than one
entry defined.
Signed-off-by: Jon Hunter
---
Here is an example output from pm_genpd_summary following this change
for the
usb2-0 {
> vbus-supply = <&vdd_usb1_vbus>;
> status = "okay";
> - mode = "otg";
> + mode = "host";
> };
&
On 18/09/16 15:13, Paul Kocialkowski wrote:
> This enables the GPU node for tegra124 nyan boards, which is required to
> get graphics acceleration with nouveau on these devices.
>
> Signed-off-by: Paul Kocialkowski
> ---
> arch/arm/boot/dts/tegra124-nyan.dtsi | 8 +++-
> 1 file changed, 7 i
On 28/08/16 18:32, Paul Kocialkowski wrote:
> This switches a few interrupt definitions that were using
> GPIO_ACTIVE_HIGH as IRQ type, which is invalid.
May be you are right, but this does not describe why this is invalid.
Can you elaborate?
> Signed-off-by: Paul Kocialkowski
> ---
> arch/arm
On 28/08/16 18:32, Paul Kocialkowski wrote:
> Nyan boards come with an embedded controller that controls when to
> enable and disable the charge. Thus, it should not be left up to the
> kernel to handle that.
>
> Using the ti,external-control property allows specifying this use-case.
So the bq24
On 28/08/16 18:32, Paul Kocialkowski wrote:
> Depthcharge (the payload used with cros devices) will attempt to detect
> boards using their revision. This includes all the known revisions for
> the nyan-big board so that the dtb can be selected preferably.
May be I am missing something here, but f
On 28/08/16 18:32, Paul Kocialkowski wrote:
> Depthcharge (the payload used with cros devices) will attempt to detect
> boards using their revision. This includes all the known revisions for
> the nyan-blaze board so that the dtb can be selected preferably.
Again I am not sure what the benefit/ne
On 20/09/16 11:28, Jon Hunter wrote:
> Some devices may require more than one PM domain to operate and this is
> not currently by the PM domain framework. Furthermore, the current Linux
> 'device' structure only allows devices to be associated with a single PM
> domain a
On 20/09/16 18:53, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mardi 20 septembre 2016 à 18:41 +0100, Jon Hunter a écrit :
>> On 28/08/16 18:32, Paul Kocialkowski wrote:
>>>
>>> Depthcharge (the payload used with cros devices) will attempt
On 20/09/16 19:02, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mardi 20 septembre 2016 à 18:40 +0100, Jon Hunter a écrit :
>> On 28/08/16 18:32, Paul Kocialkowski wrote:
>>>
>>> Nyan boards come with an embedded controller that controls w
On 20/09/16 19:02, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mardi 20 septembre 2016 à 18:56 +0100, Jon Hunter a écrit :
>> On 20/09/16 18:53, Paul Kocialkowski wrote:
>>>
>>>> Old Signed by an unknown key
>>>
>>>
On 20/09/16 19:14, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mardi 20 septembre 2016 à 18:15 +0100, Jon Hunter a écrit :
>> On 28/08/16 18:32, Paul Kocialkowski wrote:
>>>
>>> This switches a few interrupt definitions that were using
>&g
On 20/09/16 19:17, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mardi 20 septembre 2016 à 13:24 +0100, Jon Hunter a écrit :
>> On 18/09/16 15:13, Paul Kocialkowski wrote:
>>>
>>> This enables the GPU node for tegra124 nyan boards, whic
On 21/09/16 09:26, Paul Kocialkowski wrote:
> * PGP Signed by an unknown key
>
> Le mercredi 21 septembre 2016 à 08:52 +0100, Jon Hunter a écrit :
>> On 20/09/16 19:14, Paul Kocialkowski wrote:
>>>
>>>> Old Signed by an unknown key
>>>
>>>
On 21/09/16 08:43, Paul Kocialkowski wrote:
...
>>> Depthcharge (the payload used with cros devices) will attempt to
>>> detect
>>> boards using their revision. This includes all the known revisions
>>> for
>>> the nyan-big board so that the dtb can be selected preferably.
>>
Hi Geert,
On 21/09/16 09:53, Geert Uytterhoeven wrote:
> Hi Jon,
>
> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter wrote:
>> Some devices may require more than one PM domain to operate and this is
>> not currently by the PM domain framework. Furthermore, the current Linux
On 21/09/16 08:56, Paul Kocialkowski wrote:
...
> Sure, this is exported at: /sys/class/power_supply/bq24735@5-0009
> Also, note that the power-supply next branch[2] has some more fixes for the
> bq24735 driver.
I tested the bq24735 on next-20160919 without any of your changes and
when connect
Hi Geert,
On 21/09/16 09:53, Geert Uytterhoeven wrote:
> Hi Jon,
>
> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter wrote:
>> Some devices may require more than one PM domain to operate and this is
>> not currently by the PM domain framework. Furthermore, the current Linux
For interrupt controllers successfully initialised early via device-tree,
mark these interrupt controllers as populated so we don't unnecessarily
create a device and populate any platform data later on in the boot
sequence when we populate all the various platform devices.
Signed-off-by
to see if the irqdomain is part of a hierarchy and
if so call irq_domain_free_irqs() to free/unmap the interrupt.
Signed-off-by: Jon Hunter
---
Please note that I have not observed issues with this, but something
that did not make sense to me from looking at the code.
kernel/irq/irqdomain.c
drivers can call a single function
to add a specific clock from device-tree.
Signed-off-by: Jon Hunter
---
Some examples of drivers that would be able to make use of this new
function are drivers/dma/tegra210-adma.c and
drivers/irqchip/irq-gic-pm.c.
drivers/base/power/clock_ops.c | 32
On 21/06/16 17:01, Vinod Koul wrote:
> On Wed, Jun 08, 2016 at 09:51:57AM +0100, Jon Hunter wrote:
>> Hi Peter,
>>
>> On 07/06/16 18:38, Peter Griffin wrote:
>>> There is no point calculating the residue if there is
>>> no txstate to store the valu
Hi Geert,
On 21/09/16 15:57, Geert Uytterhoeven wrote:
> Hi Jon,
>
> On Wed, Sep 21, 2016 at 4:37 PM, Jon Hunter wrote:
>> On 21/09/16 09:53, Geert Uytterhoeven wrote:
>>> On Tue, Sep 20, 2016 at 12:28 PM, Jon Hunter wrote:
>>>> Some devices may require mo
On 29/07/16 04:53, Masahiro Yamada wrote:
> Hi.
>
> I noticed my board would not work any more
> when pulling recent updates.
>
> I did "git-bisect" and I found the following commit is it.
>
> commit 1e2a7d78499ec8859d2b469051b7b80bad3b08aa
> Author: Jon
Hi John,
On 30/07/16 05:39, John Stultz wrote:
> Hey Jon,
> So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
> noticed the power/volume buttons stopped working.
>
> I did a manual rebased bisection and chased it down to your commit
> 1e2a7d78499e ("irqdomain: Don't set type when
On 06/09/16 19:42, Nicolin Chen wrote:
> ADMA supports non-flow controlled Memory-to-Memory direction
> transactions. So this patch just adds an initial support for
> that. It passed a simple dmatest:
> echo dma1chan0 > /sys/module/dmatest/parameters/channel
> echo 1024 > /sys/module
On 08/09/16 15:08, Jon Hunter wrote:
>
> On 06/09/16 19:42, Nicolin Chen wrote:
>> ADMA supports non-flow controlled Memory-to-Memory direction
>> transactions. So this patch just adds an initial support for
>> that. It passed a simple dmatest:
>> echo d
return sg_req;
> + return kzalloc(sizeof(struct tegra_dma_sg_req), GFP_NOWAIT);
> }
>
> static int tegra_dma_slave_config(struct dma_chan *dc,
For the Tegra bit ...
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
On 12/09/16 21:50, Nicolin Chen wrote:
> On Mon, Sep 12, 2016 at 03:34:08PM +0100, Jon Hunter wrote:
>
>>> Sorry. I forgot to mention that the TEGRA210_CLK_APE_SLCG_OVR
>>> clock is required for the tests. So I cherry-picked 2 patches
>>> from your audio bran
single
> set of constants to index the array of power domains.
>
> Fixes: 0159ec670763 ("PM / Domains: Verify the PM domain is present when
> adding a provider")
> Signed-off-by: Tomeu Vizoso
> Cc: Jon Hunter
> Cc: Heiko Stuebner
> ---
> drivers/base/powe
single
> set of constants to index the array of power domains.
>
> Fixes: 0159ec670763 ("PM / Domains: Verify the PM domain is present when
> adding a provider")
> Signed-off-by: Tomeu Vizoso
> Cc: Jon Hunter
> Cc: Heiko Stuebner
>
> ---
>
> v2: Als
On 05/08/16 19:12, John Stultz wrote:
> On Sat, Jul 30, 2016 at 1:07 AM, Thomas Gleixner wrote:
>> On Fri, 29 Jul 2016, John Stultz wrote:
>>> Hey Jon,
>>> So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
>>> noticed the power/volume buttons stopped working.
>>>
>>> I did a manu
On 06/08/16 00:45, John Stultz wrote:
> On Mon, Aug 1, 2016 at 3:26 AM, Jon Hunter wrote:
>> Hi John,
>>
>> On 30/07/16 05:39, John Stultz wrote:
>>> Hey Jon,
>>> So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
>>> noticed the
Hi Wolfram,
On 11/08/16 11:16, Jon Hunter wrote:
> Add runtime-pm and pinctrl support for Tegra I2C driver.
>
> The first 4 patches are trivial clean-up/simplification changes.
>
> Jon Hunter (6):
> i2c: tegra: Add missing new line characters
> i2c: tegra: Remove no
On 24/08/16 14:37, Mirza Krak wrote:
> From: Mirza Krak
>
> Document the devicetree bindings for the Generic Memory Interface (GMI)
> bus driver found on Tegra SOCs.
>
> Signed-off-by: Mirza Krak
> ---
> Changes in v2:
> - Updated examples and some information
On 25/08/16 20:26, Wolfram Sang wrote:
> * PGP Signed by an unknown key
>
>
>> @@ -407,32 +410,39 @@ static inline int tegra_i2c_clock_enable(struct
>> tegra_i2c_dev *i2c_dev)
>> return ret;
>> }
>> }
>> +
>> ret = clk_enable(i2c_dev->div_clk);
>>
On 25/08/16 20:33, Wolfram Sang wrote:
> * PGP Signed by an unknown key
>
> On Thu, Aug 11, 2016 at 11:16:56AM +0100, Jon Hunter wrote:
>> Tegra has only supported device-tree for platform/board configuration
>> for quite some time now and so simplify the Tegra I2C driver by
On 26/08/16 05:53, Mirza Krak wrote:
...
>> I have an idea which is following:
>>
>> gmi@7009 {
>> status = "okay";
>> #address-cells = <2>;
>> #size-cells = <1>;
>> ranges = <4 0 0x4800 0x0004>;
>>
>> cs4 {
>> compatible
+ dev_err(dev, "fail to enable clock.\n");
> + return ret;
> + }
> +
> + reset_control_assert(priv->rst);
> + udelay(2);
> + reset_control_deassert(priv->rst);
> +
> + tegra_gmi_parse_dt(dev, priv);
> + tegra_gmi_init(dev, priv);
> +
> + ret = of_platform_default_populate(dev->of_node, NULL, dev);
> + if (ret < 0) {
> + dev_err(dev, "fail to create devices.\n");
> + clk_disable_unprepare(priv->clk);
> + reset_control_assert(priv->rst);
nit ... I would assert the reset first and then disable the clock. This
allows the reset a few clocks to reset the logic.
Do you also need to clear the GO bit like in the remove here for
consistency? Could be worth adding a helper function to do this.
> + return ret;
> + }
> +
> + dev_set_drvdata(dev, priv);
> +
> + return 0;
> +}
> +
> +static int tegra_gmi_remove(struct platform_device *pdev)
> +{
> + struct tegra_gmi_priv *priv = dev_get_drvdata(&pdev->dev);
> + u32 config;
> +
> + of_platform_depopulate(&pdev->dev);
> +
> + config = readl(priv->base + TEGRA_GMI_CONFIG);
> + config &= ~TEGRA_GMI_CONFIG_GO;
> + writel(config, priv->base + TEGRA_GMI_CONFIG);
> +
> + clk_disable_unprepare(priv->clk);
> + reset_control_assert(priv->rst);
I would re-order the reset and clock here as well.
Otherwise ...
Reviewed-by: Jon Hunter
Cheers
Jon
--
nvpublic
Checkpatch warns about some lines over 80 characters in the Tegra I2C
driver and so fix these.
While we are at it, prefix the second instance of "STOP condition" in
the comment with a "the".
Signed-off-by: Jon Hunter
---
drivers/i2c/busses/i2c-tegra.c | 10 ++---
Add runtime-pm and pinctrl support for Tegra I2C driver.
The first 6 patches are trivial clean-up/simplification changes.
Changes since V1:
- Fixed cppcheck warning reported by Wolfram
- Added 3 more clean-up patches to fix some checkpatch issues
Jon Hunter (9):
i2c: tegra: Fix lines over 80
Checkpatch warns about missing blank lines after declarations in the
Tegra I2C driver and so fix these.
Note that the initialisation of 'val' to zero in tegra_dvc_init() is
unnecessary and so remove this.
Signed-off-by: Jon Hunter
---
drivers/i2c/busses/i2c-tegra.c | 19
Checkpatch warns about spacing around the '<<' operator in the Tegra I2C
driver and so fix these by converting the bit definitions that are using
this operator to use the BIT macro.
Signed-off-by: Jon Hunter
---
drivers/i2c/busses/i2c-tegra.c | 66 +
Tegra has only supported device-tree for platform/board configuration
for quite some time now and so simplify the Tegra I2C driver by dropping
code for non device-tree platforms/boards.
Signed-off-by: Jon Hunter
---
drivers/i2c/busses/i2c-tegra.c | 12 +++-
1 file changed, 3 insertions
All Tegra I2C devices have the name "Tegra I2C adapter" which is not
very useful when viewing the I2C adapter names via the sysfs. Therefore,
use the device name, which is unique for each I2C device, instead.
Signed-off-by: Jon Hunter
Acked-by: Laxman Dewangan
---
drivers/i2c/
function tegra_i2c_flush_fifos() because
it can only be 0 or -ETIMEDOUT.
Signed-off-by: Jon Hunter
Acked-by: Laxman Dewangan
---
drivers/i2c/busses/i2c-tegra.c | 60 --
1 file changed, 46 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/busses/i2c-te
t() is successful and return the error code from
tegra_i2c_init().
Signed-off-by: Jon Hunter
Acked-by: Laxman Dewangan
---
drivers/i2c/busses/i2c-tegra.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-t
unctions that set the state of the pins
check to see if the devices has pins associated and will return zero
if they do not. Therefore, it is safe to call these pinctrl functions
even for I2C devices that do not have any pins associated.
Signed-off-by: Jon Hunter
Acked-by: Laxman Dewangan
---
driv
Add missing new line characters for the various error messages.
Signed-off-by: Jon Hunter
Acked-by: Laxman Dewangan
---
drivers/i2c/busses/i2c-tegra.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
On 26/08/16 16:56, Wolfram Sang wrote:
> * PGP Signed by an unknown key
>
> On Fri, Aug 26, 2016 at 02:08:56PM +0100, Jon Hunter wrote:
>> Add runtime-pm and pinctrl support for Tegra I2C driver.
>>
>> The first 6 patches are trivial clean-up/simplification chan
On 26/08/16 16:55, Stephen Warren wrote:
> On 08/26/2016 07:09 AM, Jon Hunter wrote:
>> On Tegra124/132 the pins for I2C6 are shared with the Display Port AUX
>> (DPAUX) channel and on Tegra210 the pins for I2C4 and I2C6 are shared
>> with DPAUX1 and DPAUX0, respectively. Th
; the new tight integration.
I have reviewed this series and tested on Tegra, so for the series ...
Reviewed-by: Jon Hunter
Tested-by: Jon Hunter
We would really like to get support for Tegra186 GPIO in v4.15, so
please let us know if you think that this is do-able.
Cheers
Jon
--
nvpublic
Ping!
On 23/10/17 09:47, Jon Hunter wrote:
> Hi Linus,
>
> On 16/10/17 19:09, Jon Hunter wrote:
>> Hi Linus,
>>
>> On 13/10/17 16:49, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> Hi Linus,
>>>
>>> here's the
no delay was needed. However, the EC SPI driver has
been updated to always initialise the 'last_transfer_ns' variable
during probe and therefore, it is no longer necessary to test if it
is zero. Remove the code that checks if this variable is zero.
Signed-off-by: Jon Hunter
---
transfer was sent via the
variable 'last_transfer_ns'. To prevent the very first transfer being
sent too soon, initialise the 'last_transfer_ns' variable after calling
spi_setup() and before sending the first SPI message.
Signed-off-by: Jon Hunter
---
Looks like this issue has bee
transfer was sent via the
variable 'last_transfer_ns'. To prevent the very first transfer being
sent too soon, initialise the 'last_transfer_ns' variable after calling
spi_setup() and before sending the first SPI message.
Cc:
Signed-off-by: Jon Hunter
Reviewed-by: Brian Norris
no delay was needed. However, the EC SPI driver has
been updated to always initialise the 'last_transfer_ns' variable
during probe and therefore, it is no longer necessary to test if it
is zero. Remove the code that checks if this variable is zero.
Signed-off-by: Jon Hunter
Reviewed-by: Bria
1 - 100 of 1935 matches
Mail list logo
