Hi,
On Thursday 21 August 2014 10:13 PM, Tony Lindgren wrote:
> Commit 30a70b026b4cd ("usb: musb: fix obex in g_nokia.ko causing kernel
> panic") attempted to fix runtime PM handling for PHYs that are on the
> I2C bus. Commit 3063a12be2b0 (usb: musb: fix PHY power on/off) then
> changed things aro
On August 21, 2014 11:48:40 PM CEST, Felipe Balbi wrote:
>Hi,
>
>On Thu, Aug 21, 2014 at 11:41:17PM +0200, Frans Klaver wrote:
>> On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
>> > On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
>> > > On Tue, Aug 19, 2014 at 01:57:02
Hi,
On Thu, Aug 21, 2014 at 11:41:17PM +0200, Frans Klaver wrote:
> On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
> > On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> > > On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > > > On Tue, Aug 19, 2014 at 02
On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
> On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> > On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > > > At 3.6Mbaud, with slightly over
On 08/21/2014 01:03 PM, Dmitry Torokhov wrote:
I believe I have taken care of other concerns on v2, but..Arrgh.. I
did not reply to this comment..
> BTW, I do not think you need to use of_node_get/put here, it's not going
> anywhere.
It has been mentioned as a good practice to ensure we use get_p
Many palmas family of PMICs have support for interrupt based power
button. This allows the device to notify the processor of external
push button events over the shared palmas interrupt. However, this
event is generated only during a "press" operation. Software is
supposed to poll(sigh!) for detect
* Sebastian Andrzej Siewior [140821 01:37]:
> On 08/15/2014 11:02 PM, Tony Lindgren wrote:
> > * Sebastian Andrzej Siewior [140815 11:13]:
> >> +#ifdef CONFIG_SERIAL_8250_DMA
> >> + if (pdev->dev.of_node) {
> >> + /*
> >> + * Oh DMA support. If there are no DMA properties in t
* Sebastian Andrzej Siewior [140821 04:04]:
> On 08/15/2014 11:07 PM, Tony Lindgren wrote:
> > Nice, now it mostly works for me with off-idle too :) That is as long
> > as I have the DMA channels commented out in the .dts file.
> >
> > And I'm still seeing an occasional hang with pstore console j
On Wed, Aug 20, 2014 at 04:03:46PM +0300, Jyri Sarha wrote:
> Could we drop the SoC id completely and make it just
> "beaglebone-black-audio"?
> The board design is the unique factor here, not the SoC. McASP block can be
> found from several TI SoCs.
That's a lot more sensible, yes.
signature.
On Thu, Aug 21, 2014 at 12:37:15PM -0500, Nishanth Menon wrote:
> On 12:32-20140821, Murphy, Dan wrote:
> > On 08/21/2014 12:19 PM, Menon, Nishanth wrote:
> > > On 08/21/2014 11:59 AM, Murphy, Dan wrote:
> > > [...]
> > > Ooops.. mis
On 08/21/2014 12:37 PM, Menon, Nishanth wrote:
> On 12:32-20140821, Murphy, Dan wrote:
>> On 08/21/2014 12:19 PM, Menon, Nishanth wrote:
>>> On 08/21/2014 11:59 AM, Murphy, Dan wrote:
>>> [...]
>>> Ooops.. missed answering one addition statement:
>>>
On 12:32-20140821, Murphy, Dan wrote:
> On 08/21/2014 12:19 PM, Menon, Nishanth wrote:
> > On 08/21/2014 11:59 AM, Murphy, Dan wrote:
> > [...]
> > Ooops.. missed answering one addition statement:
> >
> >>> + of_property_read_u32(np, "ti,palmas-lo
On 08/21/2014 12:19 PM, Menon, Nishanth wrote:
> On 08/21/2014 11:59 AM, Murphy, Dan wrote:
> [...]
> Ooops.. missed answering one addition statement:
>
>>> + of_property_read_u32(np, "ti,palmas-long-press-seconds", &val);
>>
>> Probably should check the return to make sure the value exists and
* Felipe Balbi [140821 10:09]:
> On Thu, Aug 21, 2014 at 09:43:46AM -0700, Tony Lindgren wrote:
> > @@ -744,6 +778,9 @@ static int twl4030_usb_probe(struct platform_device
> > *pdev)
> > return status;
> > }
> >
> > + pm_runtime_mark_last_busy(&pdev->dev);
> > + pm_runtime_p
On 08/21/2014 11:59 AM, Murphy, Dan wrote:
[...]
Ooops.. missed answering one addition statement:
>> +of_property_read_u32(np, "ti,palmas-long-press-seconds", &val);
>
> Probably should check the return to make sure the value exists and that is is
> within an expected range.
It is an optional
On 08/21/2014 11:59 AM, Murphy, Dan wrote:
Thanks for the review.
[..]
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> I don't see any reboot calls made do we need this?
Arrgh.. yes. will drop.
[..]
>> +/**
>> + *
On Thu, Aug 21, 2014 at 12:05 PM, Dmitry Torokhov
wrote:
>
>
> You can not use free_irq with devm-managed resources. As I mentioned, since
> you
> need manual unwinding, I'd rather you not use managed resources in the driver
> at all.
ok. will drop all devm_ ops in the next version.
---
Regards
On Thu, Aug 21, 2014 at 09:48:04AM -0700, Tony Lindgren wrote:
> Commit 249751f22380 ("usb: phy: twl4030-usb: poll for ID disconnect")
> added twl4030_id_workaround_work() to deal with lost interrupts
> after ID pin goes down. However, this currently only works for the
> insertion. The PHY interrup
On Thu, Aug 21, 2014 at 09:43:46AM -0700, Tony Lindgren wrote:
> Commit 30a70b026b4cd ("usb: musb: fix obex in g_nokia.ko causing kernel
> panic") attempted to fix runtime PM handling for PHYs that are on the
> I2C bus. Commit 3063a12be2b0 (usb: musb: fix PHY power on/off) then
> changed things aro
Hi Nishanth,
On Thu, Aug 21, 2014 at 11:02:15AM -0500, Nishanth Menon wrote:
> +
> + ret = input_register_device(input_dev);
> + if (ret) {
> + free_irq(irq, pwron);
You can not use free_irq with devm-managed resources. As I mentioned, since you
need manual unwinding, I'd rath
On 08/21/2014 11:04 AM, Menon, Nishanth wrote:
> Many palmas family of PMICs have support for interrupt based power
> button. This allows the device to notify the processor of external
> push button events over the shared palmas interrupt. However, this
> event is generated only during a "press" op
Commit 249751f22380 ("usb: phy: twl4030-usb: poll for ID disconnect")
added twl4030_id_workaround_work() to deal with lost interrupts
after ID pin goes down. However, this currently only works for the
insertion. The PHY interrupts are not working after disconnecting
an USB-A device from the board,
Commit 30a70b026b4cd ("usb: musb: fix obex in g_nokia.ko causing kernel
panic") attempted to fix runtime PM handling for PHYs that are on the
I2C bus. Commit 3063a12be2b0 (usb: musb: fix PHY power on/off) then
changed things around to enable of PHYs that rely on runtime PM.
These changes however b
With the recent pinctrl-single changes, SoCs such as Texas
Instrument's OMAP processors can treat wake-up events from deeper idle
states as interrupts.
Let's add support for the optional second interrupt for wake-up
events. And then SoC can wakeup and handle the event using it's
regular handler.
Many palmas family of PMICs have support for interrupt based power
button. This allows the device to notify the processor of external
push button events over the shared palmas interrupt.
Document the hardware support for the same.
Signed-off-by: Nishanth Menon
---
Changes in v2:
- Added deboun
Many Palmas PMIC variants have support for power button feature. This
feature depends on certain One Time Program (OTP) and board pull
configurations (POWERHOLD signal). However, on many platforms such
as DRA72-evm, OMAP5-uevm, this may be used to generate input events
similar to twl4030-pwrbutton.
Many palmas family of PMICs have support for interrupt based power
button. This allows the device to notify the processor of external
push button events over the shared palmas interrupt. However, this
event is generated only during a "press" operation. Software is
supposed to poll(sigh!) for detect
Hi Peter,
On Thu, Aug 21, 2014 at 03:03:47PM +0100, Peter Griffin wrote:
> Hi Felipe,
>
> On Thu, 21 Aug 2014, Felipe Balbi wrote:
>
> > > Currently (in the vendor tree) one of the phys lives in
> > > drivers/usb/phy and the other in drivers/phy.
> > > I believe that is because one is only a usb
Hi Felipe,
On Thu, 21 Aug 2014, Felipe Balbi wrote:
> > Currently (in the vendor tree) one of the phys lives in
> > drivers/usb/phy and the other in drivers/phy.
> > I believe that is because one is only a usb phy and the other is a
> > multi function phy which can drive PCI-E or USB3.
>
> right
On 16:47-20140821, Tero Kristo wrote:
> In some cases, clocks can switch their parent with clk_set_rate, for
> example clk_mux can do this in some cases. Current implementation of
> clk_change_rate uses un-safe list iteration on the clock children, which
> will cause wrong clocks to
Hello,
On Thu, Aug 21, 2014 at 3:37 PM, Santosh Shilimkar
wrote:
> On Thursday 21 August 2014 09:19 AM, Nishanth Menon wrote:
>> When viewing the /proc/interrupts, there is no information about which
>> GPIO bank a specific gpio interrupt is hooked on to. This is more than a
>> bit irritating as
On Thu, Aug 21, 2014 at 02:33:40PM +0100, Peter Griffin wrote:
> Hi Felipe,
>
> Thanks for reviewing, see my comments below: -
>
> On Wed, 20 Aug 2014, Felipe Balbi wrote:
>
> > > + dwc3: dwc3@990 {
> > > + compatible = "snps,dwc3";
> > > + reg = <0x0990
Previously, the TI clock driver initialized all the clocks hierarchically
under each separate clock provider node. Now, each clock that requires
IO access will instead check their parent node to find out which IO range
to use.
This patch allows the TI clock driver to use a few new features provide
On Thu, Aug 21, 2014 at 8:44 AM, Tero Kristo wrote:
> On 08/18/2014 07:56 PM, Nishanth Menon wrote:
>>
>> Hi,
>> The following patches are based on v3.17-rc1
>> Prior to this series: http://slexy.org/view/s20QH6PW4x (notice the /0 div
>> error spam at initial boot log)
>> After this series: http:/
In some cases, clocks can switch their parent with clk_set_rate, for
example clk_mux can do this in some cases. Current implementation of
clk_change_rate uses un-safe list iteration on the clock children, which
will cause wrong clocks to be parsed in case any of the clock children
change their pare
On 08/18/2014 07:56 PM, Nishanth Menon wrote:
Hi,
The following patches are based on v3.17-rc1
Prior to this series: http://slexy.org/view/s20QH6PW4x (notice the /0 div error
spam at initial boot log)
After this series: http://slexy.org/view/s20tPNXPf4
Yeah, valid findings. However, you did no
On 08/20/2014 10:39 AM, Tero Kristo wrote:
On 08/19/2014 04:22 PM, Mark Rutland wrote:
Hi Tero,
On Fri, Aug 01, 2014 at 02:15:48PM +0100, Tero Kristo wrote:
External clock provider can now be used to register external clocks
under
it. This is needed as the TI clock driver only registers clocks
On Thursday 21 August 2014 09:19 AM, Nishanth Menon wrote:
> When viewing the /proc/interrupts, there is no information about which
> GPIO bank a specific gpio interrupt is hooked on to. This is more than a
> bit irritating as such information can esily be provided back to the
> user and at times,
Hi Felipe,
Thanks for reviewing, see my comments below: -
On Wed, 20 Aug 2014, Felipe Balbi wrote:
> > + dwc3: dwc3@990 {
> > + compatible = "snps,dwc3";
> > + reg = <0x0990 0x10>;
> > + interrupts = ;
> > + dr_mode
When viewing the /proc/interrupts, there is no information about which
GPIO bank a specific gpio interrupt is hooked on to. This is more than a
bit irritating as such information can esily be provided back to the
user and at times, can be crucial for debug.
So, instead of displaying something like
Hi Felipe,
Will fix the commit log and rebase onto 3.17-rc1 for the next iteration.
regards,
Peter.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Michal,
On Mon, 18 Aug 2014, Michal Simek wrote:
> I have checked this for all xilinx drivers we have in the tree
> and I have sent similar patches.
> This problem is probably in all subsystems.
Yep
> With communication with Mark Brown. Don't you have
> cocinelle script for fixing this every
On 08/19/2014 05:12 PM, Vinod Koul wrote:
>>
>> desc = dmaengine_prep_slave_single(rxchan, …);
>> rx_cookie = dmaengine_submit(desc);
>> dma_async_issue_pending(rxchan);
>>
>> ssleep(2);
>> /* Now assume that the transfer did not start */
>> st = dmaengine_tx_status(rxchan,
On 08/15/2014 11:07 PM, Tony Lindgren wrote:
> Nice, now it mostly works for me with off-idle too :) That is as long
> as I have the DMA channels commented out in the .dts file.
>
> And I'm still seeing an occasional hang with pstore console just
> showing:
>
> [ 289.076538] In-band Error seen b
On Thursday 21 August 2014 11:21 AM, Markus Pargmann wrote:
> This patch adds a function to get the MACIDs from the am33xx SoC
> control module registers which hold unique vendor MACIDs. This is only
> used if of_get_mac_address() fails to get a valid mac address.
>
> Signed-off-by: Markus Pargmann
On 08/15/2014 11:02 PM, Tony Lindgren wrote:
> * Sebastian Andrzej Siewior [140815 11:13]:
>> +#ifdef CONFIG_SERIAL_8250_DMA
>> +if (pdev->dev.of_node) {
>> +/*
>> + * Oh DMA support. If there are no DMA properties in the DT then
>> + * we will fall back to
46 matches
Mail list logo
