Re: EDMA oftree entry for AM335x
On 06/11/2015 05:13 PM, Tony Lindgren wrote: Well, I was not. But I'm now ;) OK good to hear! I have a working version now, but... Due to the scale of the needed changes we would need different compatible string for the single hwmod version. The Linux driver itself works fine if I don't change the compatible (ti,edma3). Boots fine with the old and new DTS file, but the edma sections are not compatible anymore IMO. I don't want to rush in a new binding for it since I want to make sure that the new binding will be usable when I got the chance to rewrite the edma stack (get rid of the code from arch/arm/common/edma.c) We have the xbar support embedded in the current edma driver - not the same crossbar as we have in dra7, it is a bit more problematic (very problematic). Currently we do not have support for more than one TPCC via DT, legacy boot on SoC with more than one TPCC is also going to be interesting. Since we will need new bindings for the edma when we fix the multiple hwmods I think we should allow us some time to think about it a bit and come up with something which will work in the future and it is nice to look at it at the same time ;) And I will be away for one week... If you want I can send an RFC/DO NOT MERGE series with the code I have tomorrow in case you want to see it, but I think it will look quite a bit different at the end. -- 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: EDMA oftree entry for AM335x
* Peter Ujfalusi peter.ujfal...@ti.com [150610 04:18]: On 06/10/2015 08:10 AM, Tony Lindgren wrote: * Robert Schwebel r.schwe...@pengutronix.de [150608 04:01]: On Wed, May 06, 2015 at 07:39:52AM -0700, Tony Lindgren wrote: That may never happen considering that davinci is using it too.. It's best to not count on that happening anytime soon at least. So my current understanding is that we have the situation that the kernel warns about the oftree being wrong, but isn't able to handle an oftree that would be right. Shouldn't the warning being added when the kernel driver supports that new mechanism? This particular driver is broken and it needs to be fixed properly. I had a warning free mainline kernel without patches on my customer hardware before, so this smells a bit like a regression ... :-/ Yes sorry I'm not patching away the warning as it does not fix the driver. Peter, I assume you are busy fixing it? Well, I was not. But I'm now ;) OK good to hear! Tony -- 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: EDMA oftree entry for AM335x
On 06/10/2015 08:10 AM, Tony Lindgren wrote: * Robert Schwebel r.schwe...@pengutronix.de [150608 04:01]: On Wed, May 06, 2015 at 07:39:52AM -0700, Tony Lindgren wrote: That may never happen considering that davinci is using it too.. It's best to not count on that happening anytime soon at least. So my current understanding is that we have the situation that the kernel warns about the oftree being wrong, but isn't able to handle an oftree that would be right. Shouldn't the warning being added when the kernel driver supports that new mechanism? This particular driver is broken and it needs to be fixed properly. I had a warning free mainline kernel without patches on my customer hardware before, so this smells a bit like a regression ... :-/ Yes sorry I'm not patching away the warning as it does not fix the driver. Peter, I assume you are busy fixing it? Well, I was not. But I'm now ;) -- 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: EDMA oftree entry for AM335x
* Robert Schwebel r.schwe...@pengutronix.de [150608 04:01]: On Wed, May 06, 2015 at 07:39:52AM -0700, Tony Lindgren wrote: That may never happen considering that davinci is using it too.. It's best to not count on that happening anytime soon at least. So my current understanding is that we have the situation that the kernel warns about the oftree being wrong, but isn't able to handle an oftree that would be right. Shouldn't the warning being added when the kernel driver supports that new mechanism? This particular driver is broken and it needs to be fixed properly. I had a warning free mainline kernel without patches on my customer hardware before, so this smells a bit like a regression ... :-/ Yes sorry I'm not patching away the warning as it does not fix the driver. Peter, I assume you are busy fixing it? Regards, Tony -- 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: EDMA oftree entry for AM335x
On Wed, May 06, 2015 at 07:39:52AM -0700, Tony Lindgren wrote:
In different SoC we can have different number of CCs (OMAP-L138 has two) and
each CC can have different number of TCs associated with. In AM335x we have
one CC with 3 TC, in OMAP-L138 we have two CC, CC0 has 2 TC, CC1 has 1 TC.
The
TCs are used to set priorities, you can assign the priorities to the TCs and
you can choose to assign the transfer (channel) to a give TC.
OK
And yes, both TC and CCs can generate interrupts.
Do the TCs have a shared interrupt that could be handled by
each TC instance?
Separate IRQ lines to the ARM core, but we do not handle them right now.
OK
So it is not straight forward to separate the TC from the CC driver
(edma3).
It seems pm runtime for these four separate modules needs to be
done at the CC driver level if it can't be done separately for
each instance.
The current eDMA stack is not really flexible on this IMHO.
I think the way forward would be something like this in DT:
edma_cc: edma_cc@4900 {
compatible = ti,edma3-cc;
ti,hwmods = tpcc
reg = 0x4900 0x1,
0x44e10f90 0x40;
interrupts = 12 13 14;
#dma-cells = 1;
edma3_tc0: edma3_tc0@4980 {
compatible = ti,edma3-tc;
ti,hwmods = tptc0
};
edma3_tc1: edma3_tc1@4990 {
compatible = ti,edma3-tc;
ti,hwmods = tptc1
};
edma3_tc2: edma3_tc2@49a0 {
compatible = ti,edma3-tc;
ti,hwmods = tptc2
};
};
Yeah that would be an improvment and remove the blockers for further
hwmod work. It would still be better to have the TC probe separately
and register with CC rather than combining separate elements in DT
in a way that does not represent the hardare. There's a 7MB reserved
block inbetween there..
The driver for ti,edma3-tc would be pretty minimal, doing only pm_runtime
only
and from the CC driver we could just set the runtime status for the the TC
which we are about to submit work and decrement the runtime when the work is
done. If not work is needed for the TC it can be shot down.
OK
But this would need significant amount of work which can be done when we get
rid of the legacy (arch/arm/common/edma.c) and move to dmaengine only mode.
That may never happen considering that davinci is using it too.. It's
best to not count on that happening anytime soon at least.
So my current understanding is that we have the situation that the
kernel warns about the oftree being wrong, but isn't able to handle an
oftree that would be right.
Shouldn't the warning being added when the kernel driver supports that
new mechanism?
I had a warning free mainline kernel without patches on my customer
hardware before, so this smells a bit like a regression ... :-/
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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: EDMA oftree entry for AM335x
* Robert Schwebel r.schwe...@pengutronix.de [150504 14:34]: On Mon, May 04, 2015 at 02:24:57PM -0700, Tony Lindgren wrote: I tried this, with the patch below, but it doesn't work: With the above the tptc instances are being probed as separate device entries that do not register with tpcc without the related driver changes. I don't think we even parse the compatible = ti,tptc3 property currently. How useful is it to let the driver warn about wrong devicetrees then, when fixing the devicetrees results in a kernel not supporting it...? It's there so we can NAK new drivers if somebody tries to sneak in more stuff like that. Of course it should be fixed for the existing ones, that's the EDMA and McBSP AFAIK. Shouldn't these sort of patches being upstreamed only together with the full set of changes? Ideally these sort of patches never got merged. The right way to fix this is to first fix the driver, only then do the dts changes. However, thanks for the infos, I'll stay with the warnings for now. Yes I figured :) Regards, Tony -- 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: EDMA oftree entry for AM335x
Hi Tony,
On Mon, May 04, 2015 at 07:11:03AM -0700, Tony Lindgren wrote:
Adding Peter to Cc as well.
You didn't :)
The patch description says the device should be split into more devices
instead
of specifying several ti,hwmods entries, but unfortunately the Documentation
still suggests the above format in
Documentation/devicetree/bindings/dma/ti-edma.txt.
How would a correct entry look like?
Each tptc instance has it's own sysconfig register. This means each
one of them can be clocked and idled independently. They should be
treated as separate device instances. I believe the interrupts all
belong to the tpcc, which should be also treated as a separate
device instance.
In order to get rid of the ti,hwmods property, we want to have a
1-1-1 mapping of the compatible property, ti,hwmod property, and
the device entry.
Looking at the TRM Table 2-1. L3 Memory Map, these all are on
the L3, so they should be like this for now (assuming the
interrupts all belong to tpcc):
ocp {
...
edma: tpcc@4900 {
compatible = ti,edma3;
ti,hwmods = tpcc;
reg = 0x4900 0x1;
interrupts = 12 13 14;
#dma-cells = 1;
};
tptc0: tptc@4980 {
compatible = ti,tptc3;
ti,hwmods = tptc0;
reg = 0x4980 0x1;
};
tptc1: tptc@4990 {
compatible = ti,tptc3;
ti,hwmods = tptc1;
reg = 0x4990 0x1;
};
tptc2: tptc@49a0 {
compatible = ti,tptc3;
ti,hwmods = tptc2;
reg = 0x49a0 0x1;
};
...
};
I tried this, with the patch below, but it doesn't work:
--8-- Output with 4.1-rc1 vanilla --8--
Loading ARM Linux zImage '/mnt/mmc0.1//boot/zImage'
Loading devicetree from '/mnt/mmc0.1//boot/am335x-afi-gf.dtb'
commandline: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rootfstype=ext4
rootwait loglevel=6
[0.00] Linux version 4.1.0-rc1 (rsc@callisto) (gcc version 4.8.3
2013 (prerelease) (OSELAS.Toolchain-2013.12.2 linaro-4.8-2013.11) ) #9
PREEMPT Mon May 4 22:24:41 CEST 2015
[0.00] earlycon: no match for ttyO2,115200n8
[0.00] Kernel command line: console=ttyO2,115200n8
root=/dev/mmcblk0p2 rootfstype=ext4 rootwait loglevel=6
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
[0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB)
[0.00] lowmem : 0xc000 - 0xd000 ( 256 MB)
[0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
[0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB)
[0.00] .text : 0xc0008000 - 0xc0674ed4 (6580 kB)
[0.00] .init : 0xc0675000 - 0xc06b2000 ( 244 kB)
[0.00] .data : 0xc06b2000 - 0xc06fd3e8 ( 301 kB)
[0.00].bss : 0xc070 - 0xc073a5d8 ( 234 kB)
[0.145038] omap_hwmod: tptc0 using broken dt data from edma
[0.145247] omap_hwmod: tptc1 using broken dt data from edma
[0.145425] omap_hwmod: tptc2 using broken dt data from edma
[0.151051] omap_hwmod: debugss: _wait_target_disable failed
[0.323079] SCSI subsystem initialized
[0.356218] NFS: Registering the id_resolver key type
[0.356339] Key type id_resolver registered
[0.356354] Key type id_legacy registered
[0.518782] 47401300.usb-phy supply vcc not found, using dummy regulator
[0.532356] 47401b00.usb-phy supply vcc not found, using dummy regulator
[0.554370] Key type dns_resolver registered
[0.559333] omap_voltage_late_init: Voltage driver support not added
[0.775905] mmc0: host does not support reading read-only switch, assuming
write-enable
[1.140875] musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in a_wait_vrise (80,
SessEnd), retry #3, port1 0008010c
[1.561977] random: systemd urandom read with 17 bits of entropy available
Welcome to PTXdist / af inventions-GF!
userspace starts
--8-- Output with patch --8--
[0.00] Linux version 4.1.0-rc1+ (rsc@callisto) (gcc version 4.8.3
2013 (prerelease) (OSELAS.Toolchain-2013.12.2 linaro-4.8-2013.11) ) #10
PREEMPT Mon May 4 23:03:27 CEST 2015
[0.00] earlycon: no match for ttyO2,115200n8
[0.00] Kernel command line: console=ttyO2,115200n8
root=/dev/mmcblk0p2 rootfstype=ext4 rootwait loglevel=6
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
[0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB)
[0.00] lowmem : 0xc000 - 0xd000 ( 256 MB)
[0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
[
