Re: [PATCH v2 2/5] spi: spi-ti-qspi: add mmap mode read support
On 11/04/2015 08:11 PM, Mark Brown wrote: > On Tue, Nov 03, 2015 at 03:36:11PM +0530, Vignesh R wrote: > >> +ti_qspi_enable_memory_map(spi); >> +ti_qspi_setup_mmap_read(spi, read_opcode, addr_width, >> +dummy_bytes); >> +memcpy_fromio(buf, qspi->mmap_base + from, len); >> +*retlen = len; >> +ti_qspi_disable_memory_map(spi); > > We'll be constantly enabling and disabling memory mapping with this. > I'm not sure that's a meaningful cost given that it doesn't actually > remap anything but rather just switches hardware modes, we can always > optimise it later if it is. > Hmm, I will move the ti_qspi_disable_memory_map() call to ti_qspi_start_transfer_one(), so that mmap mode is disabled only when normal SPI bus transfer is requested. Further, "mmap_enabled" status flag can be used to determine whether mode switch is required or not. This should help to overcome enabling and disabling memory mapping between successive mmap read requests. -- Regards Vignesh -- 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
Re: [PATCH] drivers: net: cpsw: Add support for fixed-link PHY
From: Markus Brunner Date: Tue, 03 Nov 2015 22:09:51 +0100 > Add support for a fixed-link devicetree sub-node in case the the > cpsw MAC is directly connected to a non-mdio PHY/device. > > Signed-off-by: Markus Brunner Applied. -- 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
Re: [PATCH] dmaengine: edma: Add dummy driver skeleton for edma3-tptc
On Wed, Nov 04, 2015 at 10:33:27AM -0600, Felipe Balbi wrote: > Peter Ujfalusi writes: > > > The eDMA3 TPTC does not need any software configuration, but it is a > > separate IP block in the SoC. In order the omap hwmod core to be able to > > handle the TPTC resources correctly in regards of PM we need to have a > > driver loaded for it. > > This patch will add a dummy driver skeleton without probe or remove > > callbacks provided. > > > > Signed-off-by: Peter Ujfalusi > > Reported-by: Olof Johansson > > This fixes the problem I also reported on linux-omap [1] > > Tested-by: Felipe Balbi > > [1] http://marc.info/?l=linux-omap&m=144665429032014&w=2 Great, I was about to point you to this series, I will push this in -next now Thanks -- ~Vinod signature.asc Description: Digital signature
Re: [PATCH] dmaengine: edma: Add dummy driver skeleton for edma3-tptc
Peter Ujfalusi writes:
> The eDMA3 TPTC does not need any software configuration, but it is a
> separate IP block in the SoC. In order the omap hwmod core to be able to
> handle the TPTC resources correctly in regards of PM we need to have a
> driver loaded for it.
> This patch will add a dummy driver skeleton without probe or remove
> callbacks provided.
>
> Signed-off-by: Peter Ujfalusi
> Reported-by: Olof Johansson
This fixes the problem I also reported on linux-omap [1]
Tested-by: Felipe Balbi
[1] http://marc.info/?l=linux-omap&m=144665429032014&w=2
> ---
> Hi,
>
> while it would have been possible to add the edma3-tptc compatible to be
> handled
> by the edma-tpcc driver (and when the device is tptc, do nothing) it would
> make the driver code a bit harder to follow.
> I think having separate structure for the tptc looks better and if we ever
> need
> to have separate driver for the tptc it will be cleaner for us the separate
> it.
>
> This patch alone w/o any hwmod flag changes will make sure that the edma-tptc
> is
> not powered down after the kernel is finished it's booting.
>
> Regards,
> Peter
>
> drivers/dma/edma.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 31722d436a42..6b03e4e84e6b 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -269,6 +269,11 @@ static const struct of_device_id edma_of_ids[] = {
> {}
> };
>
> +static const struct of_device_id edma_tptc_of_ids[] = {
> + { .compatible = "ti,edma3-tptc", },
> + {}
> +};
> +
> static inline unsigned int edma_read(struct edma_cc *ecc, int offset)
> {
> return (unsigned int)__raw_readl(ecc->base + offset);
> @@ -2399,6 +2404,13 @@ static struct platform_driver edma_driver = {
> },
> };
>
> +static struct platform_driver edma_tptc_driver = {
> + .driver = {
> + .name = "edma3-tptc",
> + .of_match_table = edma_tptc_of_ids,
> + },
> +};
> +
> bool edma_filter_fn(struct dma_chan *chan, void *param)
> {
> bool match = false;
> @@ -2418,6 +2430,12 @@ EXPORT_SYMBOL(edma_filter_fn);
>
> static int edma_init(void)
> {
> + int ret;
> +
> + ret = platform_driver_register(&edma_tptc_driver);
> + if (ret)
> + return ret;
> +
> return platform_driver_register(&edma_driver);
> }
> subsys_initcall(edma_init);
> @@ -2425,6 +2443,7 @@ subsys_initcall(edma_init);
> static void __exit edma_exit(void)
> {
> platform_driver_unregister(&edma_driver);
> + platform_driver_unregister(&edma_tptc_driver);
> }
> module_exit(edma_exit);
>
> --
> 2.6.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
balbi
signature.asc
Description: PGP signature
commit e3faf2b8826b8ac58cdaad7f801e59e389320f0e regresses AM437x SK
Hi, with today's next (which contains commit e3faf2b8826b "ARM: DTS: am437x: Use the new DT bindings for the eDMA3" above) I can't get to getty prompt on my AM437x SK. Simply reverting that commit makes it work again. Here are some boot logs: next/master : http://hastebin.com/amunusunok reverted : http://hastebin.com/inovevosej -- balbi signature.asc Description: PGP signature
Re: [PATCH] drivers: net: cpsw: Add support for fixed-link PHY
On Wednesday 04 November 2015 02:39 AM, Markus Brunner wrote: > Add support for a fixed-link devicetree sub-node in case the the > cpsw MAC is directly connected to a non-mdio PHY/device. > > Signed-off-by: Markus Brunner Looks good to me. Acked-by: Mugunthan V N Regards Mugunthan V N -- 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
Re: [PATCH v2 2/5] spi: spi-ti-qspi: add mmap mode read support
On Tue, Nov 03, 2015 at 03:36:11PM +0530, Vignesh R wrote: > + ti_qspi_enable_memory_map(spi); > + ti_qspi_setup_mmap_read(spi, read_opcode, addr_width, > + dummy_bytes); > + memcpy_fromio(buf, qspi->mmap_base + from, len); > + *retlen = len; > + ti_qspi_disable_memory_map(spi); We'll be constantly enabling and disabling memory mapping with this. I'm not sure that's a meaningful cost given that it doesn't actually remap anything but rather just switches hardware modes, we can always optimise it later if it is. signature.asc Description: PGP signature
Re: [PATCH v2 1/5] spi: introduce mmap read support for spi flash devices
On Tue, Nov 03, 2015 at 03:36:10PM +0530, Vignesh R wrote: > + } > + mutex_lock(&master->mmap_lock_mutex); > + ret = master->spi_mtd_mmap_read(spi, from, len, retlen, buf, > + read_opcode, addr_width, > + dummy_bytes); > + mutex_unlock(&master->mmap_lock_mutex); > + if (master->auto_runtime_pm) > + pm_runtime_put(master->dev.parent); It's a bit worrying that this doesn't sync with the message queue except via the mutex: this means that we might be out of order with respect to any asynchronous transfers that are happening on the device. I'm not sure that this is a practical problem, though there is some risk of unfair scheduling that would have to be under extreme load and it might make sense to prioritise reads anyway. signature.asc Description: PGP signature
Re: [PATCH] watchdog: omap_wdt: fix null pointer dereference
On Wednesday 04 November 2015 02:20:20, Peter Robinson wrote:
> Fix issue from two patches overlapping causing a kernel oops
>
> [ 3569.297449] Unable to handle kernel NULL pointer dereference at virtual
> address 0088 [ 3569.306272] pgd = dc894000
> [ 3569.309287] [0088] *pgd=
> [ 3569.313104] Internal error: Oops: 5 [#1] SMP ARM
> [ 3569.317986] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
> xt_conntrack ebtable_filter ebtable_nat ebtable_broute bridge stp llc
> ebtables ip6table_security ip6table_raw ip6table_nat nf_conntrack_ipv6
> nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_filter ip6_tables
> iptable_security iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
> nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle musb_dsps cppi41 musb_hdrc
> phy_am335x udc_core phy_generic phy_am335x_control omap_sham omap_aes
> omap_rng omap_hwspinlock omap_mailbox hwspinlock_core musb_am335x omap_wdt
> at24 8250_omap leds_gpio cpufreq_dt smsc davinci_mdio mmc_block ti_cpsw
> cpsw_common ptp pps_core cpsw_ale davinci_cpdma omap_hsmmc omap_dma
> mmc_core i2c_dev [ 3569.386293] CPU: 0 PID: 1429 Comm: wdctl Not tainted
> 4.3.0-0.rc7.git0.1.fc24.armv7hl #1 [ 3569.394740] Hardware name: Generic
> AM33XX (Flattened Device Tree) [ 3569.401179] task: dbd11a00 ti: dbaac000
> task.ti: dbaac000
> [ 3569.406917] PC is at omap_wdt_get_timeleft+0xc/0x20 [omap_wdt]
> [ 3569.413106] LR is at watchdog_ioctl+0x3cc/0x42c
> [ 3569.417902] pc : []lr : []psr: 600f0013
> [ 3569.417902] sp : dbaadf18 ip : 0003 fp : 7f5d3bbe
> [ 3569.430014] r10: r9 : 0003 r8 : bef21ab8
> [ 3569.435535] r7 : dbbc0f7c r6 : dbbc0f18 r5 : bef21ab8 r4 :
> [ 3569.442427] r3 : r2 : r1 : 8004570a r0 : dbbc0f18
> [ 3569.449323] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
> none [ 3569.456858] Control: 10c5387d Table: 9c894019 DAC: 0051
> [ 3569.462927] Process wdctl (pid: 1429, stack limit = 0xdbaac220)
> [ 3569.469179] Stack: (0xdbaadf18 to 0xdbaae000)
> [ 3569.473790] df00:
> bef21ab8 dbf60e38 [ 3569.482441] df20: dc91b840 8004570a bef21ab8 c03988a4
> dbaadf48 dc854000 dd313850 [ 3569.491092] df40: ddf033b8 570a
> dc91b80b dbaadf3c dbf60e38 0020 c0df9250 c0df6c48 [ 3569.499741] df60:
> dc91b840 8004570a dc91b840 dc91b840 8004570a bef21ab8 0003 [
> 3569.508389] df80: c03989d4 bef21b74 7f5d3bad 0003 0036
> c020fcc4 dbaac000 [ 3569.517037] dfa0: c020fb00 bef21b74 7f5d3bad
> 0003 8004570a bef21ab8 0001 [ 3569.525685] dfc0: bef21b74 7f5d3bad
> 0003 0036 0001 7f5e4eb0 7f5d3bbe [ 3569.534334] dfe0:
> 7f5e4f10 bef21a3c 7f5d0a54 b6e97e0c a00f0010 0003 [
> 3569.543038] [] (omap_wdt_get_timeleft [omap_wdt]) from
> [] (watchdog_ioctl+0x3cc/0x42c) [ 3569.553266] []
> (watchdog_ioctl) from [] (do_vfs_ioctl+0x5bc/0x698) [
> 3569.561648] [] (do_vfs_ioctl) from []
> (SyS_ioctl+0x54/0x7c) [ 3569.569400] [] (SyS_ioctl) from
> [] (ret_fast_syscall+0x0/0x3c) [ 3569.577413] Code: e12fff1e
> e52de004 e8bd4000 e5903060 (e5933088) [ 3569.584089] ---[ end trace
> cec3039bd3ae610a ]---
>
> Cc: # v4.2+
> Cc: Guenter Roeck
> Cc: Lars Poeschel
> Signed-off-by: Peter Robinson
Peter, thank you for catching this one.
Acked-by: Lars Poeschel
> ---
> drivers/watchdog/omap_wdt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
> index d96bee0..6f17c93 100644
> --- a/drivers/watchdog/omap_wdt.c
> +++ b/drivers/watchdog/omap_wdt.c
> @@ -205,7 +205,7 @@ static int omap_wdt_set_timeout(struct watchdog_device
> *wdog,
>
> static unsigned int omap_wdt_get_timeleft(struct watchdog_device *wdog)
> {
> - struct omap_wdt_dev *wdev = watchdog_get_drvdata(wdog);
> + struct omap_wdt_dev *wdev = to_omap_wdt_dev(wdog);
> void __iomem *base = wdev->base;
> u32 value;
--
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
Re: [PATCH] dmaengine: edma: fix build without CONFIG_OF
On Wednesday 04 November 2015 11:05:54 Peter Ujfalusi wrote: > > > > I think that would be less readable, and gives no compile-time coverage > > to the contents of the edma_tc_set_pm_state function. > > Hrm, if the compiler knows that there is no need to compile the code after > the: > if (!IS_ENABLED(CONFIG_OF) || !tc) > when OF is disabled, then it does not give more compile coverage then have > empty inline function in case of !OF. No, the way it works (simplified but close enough here) is that gcc parses all the source code first and throws warnings or errors for everything that looks wrong to it, and only later throws out all code that it knows is never used before emitting the object code. The difference to the #ifdef is that the preprocessor here throws out all disabled code before it gets parsed, so we don't get warnings for it. > Not sure about it, but if we disable all optimization in gcc, then we might > get the same missing symbol? It's impossible to build the kernel with inlining disabled, because we rely on the same kind of optimization in lots of places. > > The effect is the same, so I'd rather stay with my version. > > I'm fine with both. It is up to Vinod to decide which one he prefers (I prefer > the #if #else #endif version). > > Anyways: > Acked-by: Peter Ujfalusi Thanks! Arnd -- 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
Re: [PATCH] dmaengine: edma: fix build without CONFIG_OF
On 11/04/2015 10:46 AM, Arnd Bergmann wrote:
> On Wednesday 04 November 2015 09:42:35 Peter Ujfalusi wrote:
>> On 11/03/2015 04:00 PM, Arnd Bergmann wrote:
>>> During the edma rework, a build error was introduced for the
>>> case that CONFIG_OF is disabled:
>>>
>>> drivers/built-in.o: In function `edma_tc_set_pm_state':
>>> :(.text+0x43bf0): undefined reference to `of_find_device_by_node'
>>>
>>> As the edma_tc_set_pm_state() function does nothing in case
>>> we are running without OF, this adds an IS_ENABLED() check
>>> that turns the function into an empty stub then and avoids the
>>> link error.
>>>
>>> Signed-off-by: Arnd Bergmann
>>> Fixes: ca304fa9bb76 ("ARM/dmaengine: edma: Public API to use private struct
>>> pointer")
>>
>> The actual commit this patch is fixing is:
>> 1be5336bc7ba dmaengine: edma: New device tree binding
>
> That's what I first thought, but it seems to just move around the
> call to of_find_device_by_node that was first introduced in the
> commit I mentioned. Did you build-test it successfully with
> ca304fa9bb76 and CONFIG_OF enabled? I have to admit that I
> was just guessing from the contents and did not bisect this
> fully.
Ah, I see. That of_find_device_by_node() was used by the function used to
build the unused channel list for the legacy old code. The whole unused
channel list has been removed by the new DT binding patch since it was bogus
to start with and there is no need for it anymore.
>
>>> ---
>>> Found on ARM randconfig builds with today's linux-next
>>
>> I have sanity built the kernel with omap2plus_defconfig and
>> davinci_all_defconfig since eDMA is used by these platforms and did not faced
>> with this issue, as obviously these defconfigs will result OF to be enabled.
>
> Right. The defconfigs were all fine, and this is hard to hit
> even in the randconfig builds.
I just did a sanity clean _defconfig builds and they both built fine (even w/o
this patch), phew.
>>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>>> index 31722d436a42..16713a93da10 100644
>>> --- a/drivers/dma/edma.c
>>> +++ b/drivers/dma/edma.c
>>> @@ -1560,7 +1560,7 @@ static void edma_tc_set_pm_state(struct edma_tc *tc,
>>> bool enable)
>>> struct platform_device *tc_pdev;
>>> int ret;
>>>
>>> - if (!tc)
>>> + if (!IS_ENABLED(CONFIG_OF) || !tc)
>>> return;
>>
>> Should we instead put the function inside of:
>> #if IS_ENABLED(CONFIG_OF)
>> static void edma_tc_set_pm_state(struct edma_tc *tc, bool enable)
>> {
>> ...
>> }
>> #else
>> static inline void edma_tc_set_pm_state(struct edma_tc *tc, bool enable)
>> {
>> }
>> #endif /* IS_ENABLED(CONFIG_OF) */
>
> I think that would be less readable, and gives no compile-time coverage
> to the contents of the edma_tc_set_pm_state function.
Hrm, if the compiler knows that there is no need to compile the code after the:
if (!IS_ENABLED(CONFIG_OF) || !tc)
when OF is disabled, then it does not give more compile coverage then have
empty inline function in case of !OF.
Not sure about it, but if we disable all optimization in gcc, then we might
get the same missing symbol?
> The effect is the same, so I'd rather stay with my version.
I'm fine with both. It is up to Vinod to decide which one he prefers (I prefer
the #if #else #endif version).
Anyways:
Acked-by: Peter Ujfalusi
--
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
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On 11/04/2015 10:37 AM, Vinod Koul wrote: > On Mon, Nov 02, 2015 at 05:46:05PM +0200, Peter Ujfalusi wrote: >>> Okay I have reverted the two and applied the edma patch sent, can you please >>> verify topic/edma_fix before I merge it and send my PULL request. >> >> The branch looks good. Thank you! >> It would have been great if the DTS changes for am335x/am437x would have been >> in 4.4, but I will send them for 4.5 after rc1 is out. > > Any confirmation that this fixes the reported issue before I send pull > request? Patch 'dmaengine: edma: Add dummy driver skeleton for edma3-tptc' alone is fixing the issue: https://lkml.org/lkml/2015/11/2/297 I have tested it on: OMAP-L138-EVM, am335x-evmsk, am437x-gp-evm, dra7-evm (I have local patches to enable and use eDMA). All looks fine, mmc/audio works and they use eDMA. Olof: can you run a quick test with the linked patch? Thank you, Péter -- 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
Re: [PATCH] dmaengine: edma: fix build without CONFIG_OF
On Wednesday 04 November 2015 09:42:35 Peter Ujfalusi wrote:
> On 11/03/2015 04:00 PM, Arnd Bergmann wrote:
> > During the edma rework, a build error was introduced for the
> > case that CONFIG_OF is disabled:
> >
> > drivers/built-in.o: In function `edma_tc_set_pm_state':
> > :(.text+0x43bf0): undefined reference to `of_find_device_by_node'
> >
> > As the edma_tc_set_pm_state() function does nothing in case
> > we are running without OF, this adds an IS_ENABLED() check
> > that turns the function into an empty stub then and avoids the
> > link error.
> >
> > Signed-off-by: Arnd Bergmann
> > Fixes: ca304fa9bb76 ("ARM/dmaengine: edma: Public API to use private struct
> > pointer")
>
> The actual commit this patch is fixing is:
> 1be5336bc7ba dmaengine: edma: New device tree binding
That's what I first thought, but it seems to just move around the
call to of_find_device_by_node that was first introduced in the
commit I mentioned. Did you build-test it successfully with
ca304fa9bb76 and CONFIG_OF enabled? I have to admit that I
was just guessing from the contents and did not bisect this
fully.
> > ---
> > Found on ARM randconfig builds with today's linux-next
>
> I have sanity built the kernel with omap2plus_defconfig and
> davinci_all_defconfig since eDMA is used by these platforms and did not faced
> with this issue, as obviously these defconfigs will result OF to be enabled.
Right. The defconfigs were all fine, and this is hard to hit
even in the randconfig builds.
> > diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> > index 31722d436a42..16713a93da10 100644
> > --- a/drivers/dma/edma.c
> > +++ b/drivers/dma/edma.c
> > @@ -1560,7 +1560,7 @@ static void edma_tc_set_pm_state(struct edma_tc *tc,
> > bool enable)
> > struct platform_device *tc_pdev;
> > int ret;
> >
> > - if (!tc)
> > + if (!IS_ENABLED(CONFIG_OF) || !tc)
> > return;
>
> Should we instead put the function inside of:
> #if IS_ENABLED(CONFIG_OF)
> static void edma_tc_set_pm_state(struct edma_tc *tc, bool enable)
> {
> ...
> }
> #else
> static inline void edma_tc_set_pm_state(struct edma_tc *tc, bool enable)
> {
> }
> #endif /* IS_ENABLED(CONFIG_OF) */
I think that would be less readable, and gives no compile-time coverage
to the contents of the edma_tc_set_pm_state function.
The effect is the same, so I'd rather stay with my version.
Arnd
--
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
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On Mon, Nov 02, 2015 at 05:46:05PM +0200, Peter Ujfalusi wrote: > > Okay I have reverted the two and applied the edma patch sent, can you please > > verify topic/edma_fix before I merge it and send my PULL request. > > The branch looks good. Thank you! > It would have been great if the DTS changes for am335x/am437x would have been > in 4.4, but I will send them for 4.5 after rc1 is out. Any confirmation that this fixes the reported issue before I send pull request? -- ~Vinod -- 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
