On Fri, 7 Aug 2015 07:13:09 +0200 Sebastian Reichel
wrote:
> Hi,
>
> This actually slipped through my review. IMHO madc should be
> accessed through IIO, as already done for twl4030-madc-battery
> and rx51-battery. That way the custom API can be removed at
> some point.
>
> Anyway, I queued the
I managed to mess up omap3 power domain operations with commit
7c80a3f89c51 ("ARM: OMAP2+: Add custom prwdm_operations for 81xx
to support dm814x"), by default we should keep on using the
omap3_pwrdm_operations, only 81xx needs custom handling.
This causes omap3 PM to break so we won't hit off mod
Hi,
This actually slipped through my review. IMHO madc should be
accessed through IIO, as already done for twl4030-madc-battery
and rx51-battery. That way the custom API can be removed at
some point.
Anyway, I queued the below patch with Tony's ACK to fix the build
issue in next.
On Fri, Aug 07,
am4372-rtc string was already part of dts, introduced to identify
the rtc specific to am4372 family of SoCs. It was removed in one of the
previous patches. Adding back the same with appropriate documentation.
Signed-off-by: Keerthy
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt | 1 +
ar
Hi,
I am using a 4460 Based custom board & i want to debug linux using
Trace32. Could anyone share the cmm files required for debugging
omap4460.
I also request you to share any related documentation for debugging
omap using trace32.
Thanks and Regards,
ryan
--
To unsubscribe from this list:
* NeilBrown [150806 20:48]:
>
> Thanks, I did get notified about that by Fengguang's test robot, but
> it's still on my list
>
> I guess making CHARGER_TWL4030 auto-select TWL4030_MADC would not be
> acceptable? That would pull in IIO (it didn't use to...).
>
> If this OK?
Looks OK to me
On Thu, 6 Aug 2015 20:11:16 -0700 Tony Lindgren
wrote:
> * NeilBrown [150729 17:28]:
> > --- a/drivers/power/twl4030_charger.c
> > +++ b/drivers/power/twl4030_charger.c
> > static int twl4030_charger_update_current(struct twl4030_bci *bci)
> > {
> > int status;
> > + int cur;
> > uns
* Linus Walleij [150716 01:38]:
> On Wed, Jun 24, 2015 at 4:54 PM, Grygorii Strashko
> wrote:
>
> > From: Grygorii Strashko
> >
> > Add missed spin_unlock_irqrestore in omap_gpio_irq_type when
> > omap_set_gpio_triggering() is failed.
> >
> > It fixes static checker warning:
> >
> > dri
* NeilBrown [150729 17:28]:
> --- a/drivers/power/twl4030_charger.c
> +++ b/drivers/power/twl4030_charger.c
> static int twl4030_charger_update_current(struct twl4030_bci *bci)
> {
> int status;
> + int cur;
> unsigned reg, cur_reg;
> u8 bcictl1, oldreg, fullreg;
> bo
* Keerthy [150806 09:51]:
>
> Shall i re-do this patch without removing am4372-rtc? If you can drop this i
> can re-do without removing the original am4372 compatible.
OK please send a patch reverting the compatible change against the
current omap-for-v4.3/dt-v2 branch. Please also describe why
On Fri, Aug 7, 2015 at 6:22 AM, Peter Hurley wrote:
> I agree; this is what we should do first because someone might want it
> for backports.
Got an idea how far this can be ported back?
I'm being hampered by severe performance issues on a
beagleboneblack-like device (am335x) running on 3.18 ker
On Thu, Aug 06, 2015 at 06:14:00PM +0200, Geert Uytterhoeven wrote:
> On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
> >> On the whole following are my requirements:
> >> 1. to be able to communicate with non -flash
On Thu, Aug 06, 2015 at 07:01:56PM +0100, Mark Brown wrote:
> On Thu, Aug 06, 2015 at 12:00:47PM +0100, Build bot for Mark Brown wrote:
>
> Today's linux-next fails to build an ARM allmodconfig with:
>
> > ../drivers/iommu/omap-iommu-debug.c:138:2: error: void value not ignored as
> > it ought t
Signed-off-by: Jyri Sarha
---
drivers/video/fbdev/omap2/dss/dss-of.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/omap2/dss/dss-of.c
b/drivers/video/fbdev/omap2/dss/dss-of.c
index 928ee63..ab6ef16 100644
--- a/drivers/video/fbdev/omap2/dss/dss-of.c
+++ b/drivers/video/
I found couple of refcounting issues related to OMAP DSS of-node
handling. Second patch should fix the "ERROR: Bad of_node_put() on
/encoder@0/ports/port@1" -problem.
In the long run it would make sense start using of_graph_*() functions
in OMAP DSS too. However the semantics of of_graph_*() funct
The only user of dss_of_port_get_parent_device() function is
omap_dss_find_output_by_port_node() and it assumes the refcount of the
port parameter is not decremented by the call.
Signed-off-by: Jyri Sarha
---
drivers/video/fbdev/omap2/dss/dss-of.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
On 08/06/2015 09:59 AM, Sebastian Andrzej Siewior wrote:
> On 08/06/2015 02:31 PM, Sebastian Andrzej Siewior wrote:
>
> Hi Peter,
>
>>> I'll look at/test this this weekend, ok?
>>
>> Sure. I'm currently re-spinning the patches so have everything in
>> proper pieces. While at it I will take a look
On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
> 1.Write to flash config register via config port to switch to QUAD MODE
> (or any mode that flash supports).
> 2. Populate QSPI_SPI_SETUP_REGx with flash read command, number of
> address bytes to use and dummy bytes required.
These thi
On 6 August 2015 at 18:14, Geert Uytterhoeven wrote:
> On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux
> wrote:
>> On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
>>> On the whole following are my requirements:
>>> 1. to be able to communicate with non -flash SPI devices via c
On Thu, Aug 06, 2015 at 12:00:47PM +0100, Build bot for Mark Brown wrote:
Today's linux-next fails to build an ARM allmodconfig with:
> ../drivers/iommu/omap-iommu-debug.c:138:2: error: void value not ignored as
> it ought to be
caused by a combination of 1ba2f20ac (fs/seq_file: convert int
seq
On Thursday 06 August 2015 07:46 PM, Felipe Balbi wrote:
On Thu, Aug 06, 2015 at 06:55:57AM +0530, Keerthy wrote:
On Wednesday 05 August 2015 10:21 PM, Felipe Balbi wrote:
On Wed, Aug 05, 2015 at 09:48:08PM +0530, Keerthy wrote:
On Wednesday 05 August 2015 09:44 PM, Felipe Balbi wrote:
On Thu, Aug 06, 2015 at 02:51:29PM +0100, Russell King - ARM Linux wrote:
> The M25P80 driver just appends additional bytes to the message to
> achieve this:
>
> struct m25p *flash = nor->priv;
> unsigned int dummy = nor->read_dummy;
>
> /* convert the dummy cycles to the
On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux
wrote:
> On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
>> On the whole following are my requirements:
>> 1. to be able to communicate with non -flash SPI devices via config port
>> ( this functionality is supported by current dr
On Thu, Aug 06, 2015 at 01:42:32PM +0200, Michal Suchanek wrote:
> On 6 August 2015 at 13:23, Mark Brown wrote:
> > Sure, but at the end of the day it's just emitting standard SPI messages
> > which don't know anything about flash. If those messages are a sensible
> > interface here then why bot
Add workaround for Cortex-A15 ARM erratum 801819 which says in summary
that "A livelock can occur in the L2 cache arbitration that might
prevent a snoop from completing. Under certain conditions this can
cause the system to deadlock. "
Recommended workaround is as follows:
Do both of the following
On Friday, July 31, 2015 9:25 PM, Kishon Vijay Abraham I wrote:
>
> This series adds PM support to pci-dra7xx so that PCI clocks can be disabled
> during suspend and enabled back during resume without affecting
> PCI functionality.
>
> Changes from v4:
> *) Fixed a bug caused by sending incomplet
HI,
On Thu, Aug 06, 2015 at 09:40:26AM +0200, Yegor Yefremov wrote:
> I performed a stress test with several FT4232H chips connected to a
how many ?
> hub, that is attached to one of the musb ports. So far the test was
> successful for several hours. But I've seen following warnings:
>
> musb_h
On Thu, Aug 06, 2015 at 06:55:57AM +0530, Keerthy wrote:
>
>
> On Wednesday 05 August 2015 10:21 PM, Felipe Balbi wrote:
> >On Wed, Aug 05, 2015 at 09:48:08PM +0530, Keerthy wrote:
> >>
> >>
> >>On Wednesday 05 August 2015 09:44 PM, Felipe Balbi wrote:
> >>>On Wed, Aug 05, 2015 at 09:21:05PM +053
On 08/06/2015 02:31 PM, Sebastian Andrzej Siewior wrote:
Hi Peter,
>> I'll look at/test this this weekend, ok?
>
> Sure. I'm currently re-spinning the patches so have everything in
> proper pieces. While at it I will take a look at x_char.
So now that I actually look at it. If I read this right
On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote:
> On the whole following are my requirements:
> 1. to be able to communicate with non -flash SPI devices via config port
> ( this functionality is supported by current driver, I dont want to
> break it). Or pump any spi_message on to SPI bu
Hi,
On Wed, Aug 05, 2015 at 11:14:45AM -0500, Felipe Balbi wrote:
> for them. Sure, it wasn't documented, but that's a problem of commit
> 73456012734b80442b33916406cfd13bf1b73acb (ARM: dts: AM4372: add few
> nodes) which, essentially, added that compatible flag without
> documenting it.
It was
On 08/06/2015 02:27 PM, Peter Hurley wrote:
> Hi Sebastian,
Hi Peter,
> On 08/04/2015 07:58 AM, Sebastian Andrzej Siewior wrote:
>> On 08/03/2015 09:32 PM, Peter Hurley wrote:
>>
You mean a function in 8250-dma API which does what I did just here
with the wait_event() and the wake_up in
Hi Sebastian,
On 08/04/2015 07:58 AM, Sebastian Andrzej Siewior wrote:
> On 08/03/2015 09:32 PM, Peter Hurley wrote:
>
>>> You mean a function in 8250-dma API which does what I did just here
>>> with the wait_event() and the wake_up in the callback? That way I could
>>> move the termios_wait into
On 08/06/2015 03:52 PM, Russell King - ARM Linux wrote:
> On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
>> Disclaimer: I am not familiar with the hardware for which this patch
>> adds support.
>>
>> However, I am familiar m25p80.c and as I understand it the controller
>> is bas
On 6 August 2015 at 13:23, Mark Brown wrote:
> On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
>
>> However, I am familiar m25p80.c and as I understand it the controller
>> is basically supposed to implement m25p80.c in hardware when this flag
>> is set.
>
> But what in concrete t
On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
> However, I am familiar m25p80.c and as I understand it the controller
> is basically supposed to implement m25p80.c in hardware when this flag
> is set.
But what in concrete terms is that supposed to mean? It's currently
just an
The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590:
Linux 4.2-rc2 (2015-07-12 15:10:30 -0700)
are available in the git repository at:
https://github.com/t-kristo/linux-pm.git for-4.3/ti-clk-dt
for you to fetch changes up to dff8a207815a605872dfc5bffc1bae1cad29d87c:
On 6 August 2015 at 12:22, Russell King - ARM Linux
wrote:
> On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
>> Disclaimer: I am not familiar with the hardware for which this patch
>> adds support.
>>
>> However, I am familiar m25p80.c and as I understand it the controller
>> is b
On Thu, Aug 06, 2015 at 11:22:25AM +0100, Russell King - ARM Linux wrote:
> If that's the case, then maybe you should consider whether using the SPI
> bus infrastructure is really the best way forward. Would it make more
> sense instead to adopt a different software structure, something more
> hi
The following changes since commit f5887fe5d14181aef0653ab04f60988252d42461:
ARM: OMAP2+: Add custom abort handler for t410 (2015-07-23 22:33:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v4.3/dt-pt3
for you
The following changes since commit 9908ac3daa3da2d236b5406b95d0865ddb8b29c4:
ARM: dts: Correct audio input route & set mic bias for am335x-pepper
(2015-07-15 03:03:01 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-fo
On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
> Disclaimer: I am not familiar with the hardware for which this patch
> adds support.
>
> However, I am familiar m25p80.c and as I understand it the controller
> is basically supposed to implement m25p80.c in hardware when this flag
On 6 August 2015 at 11:02, Mark Brown wrote:
> On Wed, Aug 05, 2015 at 02:56:09PM +0200, Michal Suchanek wrote:
>> On 5 August 2015 at 14:44, Mark Brown wrote:
>> > On Wed, Aug 05, 2015 at 02:40:01PM +0200, Michal Suchanek wrote:
>
>> >> I don't think sending 03 or other random byte as the first
On 08/06/2015 09:26 AM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I [150805 07:59]:
>> Hi Tony,
>>
>> On Wednesday 05 August 2015 03:17 PM, Tony Lindgren wrote:
>>> * Kishon Vijay Abraham I [150727 04:27]:
vsel_reg and enable_reg of the pbias regulator descriptor should actually
hav
* Alexandre Belloni [150806 02:50]:
> On 06/08/2015 at 12:36:54 +0300, Grygorii Strashko wrote :
> > Pls, correct me if I'm not right. Is below what you propose?
> >
> > Doard dts:
> > / {
> > rtc_32k_ext_clk: rtc_osc_xi_clkin32_ext {
> > #clock-cells = <0>;
> > compatible = "fixed-clock
On 06/08/2015 at 12:36:54 +0300, Grygorii Strashko wrote :
> Pls, correct me if I'm not right. Is below what you propose?
>
> Doard dts:
> / {
> rtc_32k_ext_clk: rtc_osc_xi_clkin32_ext {
> #clock-cells = <0>;
> compatible = "fixed-clock";
> clock-frequency = <32000>;
> clo
On 06/08/2015 at 07:39:52 +0530, Keerthy wrote :
> On Wednesday 05 August 2015 06:05 PM, Alexandre Belloni wrote:
> >On 05/08/2015 at 17:31:22 +0530, Keerthy wrote :
> >>This is a special one where in the enable bit is present in the rtc register
> >>space and not in the prcm register space. Since
Hi Alexandre,
On 08/05/2015 02:43 PM, Alexandre Belloni wrote:
> On 05/08/2015 at 13:41:19 +0200, Alexandre Belloni wrote :
>> Hi,
>>
>> On 05/08/2015 at 04:13:17 -0700, Tony Lindgren wrote :
>>> * Keerthy [150805 03:53]:
Based on the board property switch the source from internal
to ext
On Wed, Aug 05, 2015 at 02:56:09PM +0200, Michal Suchanek wrote:
> On 5 August 2015 at 14:44, Mark Brown wrote:
> > On Wed, Aug 05, 2015 at 02:40:01PM +0200, Michal Suchanek wrote:
> >> I don't think sending 03 or other random byte as the first byte of a
> >> SPI transfer can be used as reliable
* Kishon Vijay Abraham I [150805 07:28]:
> Hi Roger,
>
> On Wednesday 05 August 2015 01:38 PM, Roger Quadros wrote:
> > On 05/08/15 11:02, Roger Quadros wrote:
> >> Kishon,
> >>
> >> On 04/08/15 18:30, Kishon Vijay Abraham I wrote:
> >>> Add "syscon-otghs" property and remove the deprecated "ctrl
* Kishon Vijay Abraham I [150805 07:10]:
> On Wednesday 05 August 2015 01:31 PM, Tony Lindgren wrote:
> >
> > We don't have syscon-otghs and to me it seems we need a PHY driver
> > as I pointed out at:
>
> If *syscon-otghs* is not present, then it'll fall-back to using the
> *ctrl-module*.
OK
I performed a stress test with several FT4232H chips connected to a
hub, that is attached to one of the musb ports. So far the test was
successful for several hours. But I've seen following warnings:
musb_host_rx 1973: Rx interrupt with no errors or packet!
musb_ep_program 931: broken !rx_reinit,
* Anthoine Bourgeois [150805 14:53]:
> On Wed, Aug 05, 2015 at 04:08:12AM -0700, Tony Lindgren wrote:
> >* Anthoine Bourgeois [150804 13:54]:
> >>Devkit8000 was sold with a 4.3" LCD or 7.0" or without. This patch
> >>creates one dts file per bundle.
> >
> >Applying patches 1 - 5 into omap-for-v4.
* Anthoine Bourgeois [150805 14:48]:
> Devkit8000 was sold with a 4.3" LCD or 7.0" or without. This patch
> creates one dts file per bundle.
>
> Changes since v1:
> - rebase on omap-for-v4.3/dt
Thanks applying these into omap-for-v4.3/dt-v2.
Regards,
Tony
--
To unsubscribe from this list: sen
54 matches
Mail list logo
