Re: next-20150806 build: 2 failures 52 warnings (next-20150806)
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 to be caused by a combination of 1ba2f20ac (fs/seq_file: convert int seq_vprint/seq_printf/etc... returns to void) which made seq_printf() return void and e203db293863fa15 (iommu/omap: Fix debug_read_tlb() to use seq_printf()) which has been in -next for a little while now. Whoops. Thanks for the report, I'll fix it tomorrow. Joerg -- 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: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
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 li...@arm.linux.org.uk 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 driver, I dont want to break it). Or pump any spi_message on to SPI bus directly. 2. take advantage of memory mapped port in order to increase read throughput( and use dma in future) when the slave is a m25p80 type flash. 3. handle m25p80 as well as other slave on multiple chipselects. I just need to know whether the user that requested the transfer is m25p80 driver. If yes, ti-qspi driver can take advantage of memory mapped interface, else just use config port to access SPI bus directly. The problem with this approach is that it's an abomination. It's adding a SPI-user specific hack which is detected by a specific driver. That's really not sane - what happens when we have lots of these kinds of I'm an X SPI-user with drivers detecting that? It's not maintainable in the long term. Yes, your requirements _today_ seem simple and easy, but you're only thinking about today, not tomorrow when you've moved on and someone else has to maintain the mess left behind (or delete it from mainline because they're sick of dealing with a hack.) The spi_message that is received in transfer_one_message() is too generic to imply the slave device that is on the other side of the wire. IMO, the read command does not imply that the slave is m25p80 flash (besides the read opcodes vary across vendors of m25p80 and across modes). I can see both sides of the argument. Mark is saying: if the SPI driver detects that the message to be transmitted is a read command followed by the appropriate number of dummy bytes, and then the data being read _and_ it's using quad-mode access, and the hardware generates _exactly_ that in hardware using the memory mapped mode, there is no reason _not_ to use the hardware to achieve that SPI transaction. The bus activity will be identical to what happens when the SPI controller is used manually to achieve that bus sequence. You're saying: but the documentation says you can't use it for anything except m25p80. If you look at 24.5.4.1.2, it tells you what the SFI generates on the bus, which is: 1. CS active 2. Read command byte sent 3. 1-4 address bytes sent 4. 0-3 dummy bytes sent 5. data bytes read from bus 6. CS inactive So, Mark's point is if we can detect a transaction which fits _that_ bus activity, there's no reason not to use this acceleration for the transaction. What you're failing to counter with is: we don't have enough information in the SPI driver to know how many dummy bytes there are between the address bytes and the data read from the bus. Irrespective of the dummy bytes. What if the spi device is not a FLASH ROM, but some other device, which receives a data packet that accidentally looks like an m25p80 READ command? Well, for the most part it looks like it should still work, but there could be a gotcha, but first, let's get rid of a myth there. The QSPI is _not_ specific to the M25P80. The manual says nothing about being specific to that device. What it says is that it's for SPI NOR memory. It will work with bus widths of 1, 2 or 4 data lines, so it probably works with non-M25P80 SPI NOR devices too - and the fact that the read and write commands are completely programmable suggests that using it with SPI NOR devices which do not use the M25P80 read command value is intended. The SFI is a state machine based translator which sits behind the SPI interface (look at the manual). It sequence sthe SPI bus through a series of standard SPI states which happen to be the states I detailed above. Now, the first byte of the SFI-generated SPI message can be programmed to any 8 bit value. So the first byte of the SPI message is totally under software control. The next one to four bytes which comprise the address can be controlled to by deciding where in the memory map to start reading from. Hence, the value of those bytes is also totally under software control. The number of dummy bytes can be programmed too. So far so good. So, if we know that we have a SPI message which says send 0x01 0x20 0x30, send one dummy byte, read 32 bytes, if we program the SFI to send a read command as 0x01, program an address length of 2 bytes with one dummy byte, and then read the next 32 bytes at the appropriate offset in the memory mapping to cause the next two bytes to be 0x20, 0x30, then what we end up with on the bus is: send 0x01, 0x20, 0x30 send one dummy byte That much is good, but now is the problem - how does the SFI know that we're going to require to read 32 bytes? I think the
Re: [PATCH 3/8] rtc: omap: Add external clock enabling support
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 j-keer...@ti.com [150805 03:53]:
Based on the board property switch the source from internal
to external clock. Switching to external source is needed for
rtcwake to work in low power modes.
I think this is better handled based on the compatible string
in the device driver rather than introducing a custom dts
property for it. You can just set the quirk flag in the driver
probe based on the compatible.
Why not use the clocks property? Then you can pass an external clock. If
it is present you can even get its rate if this is needed at some point
in the future. You could also disable it when going to suspend.
Actually, that was already my suggestion back in april:
http://patchwork.ozlabs.org/patch/445631/
(Please Cc: the rtc mailing list for RTC related patches so that they
get picked up by patchwork).
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;
clock-output-names = rtc_osc_xi_clkin32;
};
}
rtc {
status = okay;
clocks = sys_32k_ck, rtc_32k_ext_clk;
[optional] clock-names = int-clk, ext-clk;
};
Driver:
1) clk0 is mandatory, internal clock source
2) clk1 is optional, external clock source, so
if present - RTC driver can switch to use ext clock source
--
regards,
-grygorii
--
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
Linux 4.2.0-rc5: am335x: musb warnings
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, ep5 csr 0203 musb_host_rx 1973: Rx interrupt with no errors or packet! musb_host_rx 1973: Rx interrupt with no errors or packet! musb_host_rx 1973: Rx interrupt with no errors or packet! musb_host_rx 1973: Rx interrupt with no errors or packet! musb_ep_program 931: broken !rx_reinit, ep5 csr 0003 musb_host_rx 1973: Rx interrupt with no errors or packet! musb_ep_program 931: broken !rx_reinit, ep7 csr 0003 Is this expected behavior? The test opens serial interfaces sends data, changes baudrate, closes port and so on. Yegor -- 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 10/10] ARM: dts: omap4: Use syscon-otghs instead of ctrl-module in USB node
* Kishon Vijay Abraham I kis...@ti.com [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-module
property from MUSB devicetree node.
Since omap_control_usbotg devicetree node is no longer used, remove
it.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index b27634d..2fb49a5 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -854,12 +854,6 @@
};
};
- omap_control_usbotg: control-phy@4a00233c {
- compatible = ti,control-phy-otghs;
- reg = 0x4a00233c 0x4;
- reg-names = otghs_control;
- };
-
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = ti,omap4-musb;
reg = 0x4a0ab000 0x7ff;
@@ -872,7 +866,7 @@
multipoint = 1;
num-eps = 16;
ram-bits = 12;
- ctrl-module = omap_control_usbotg;
+ syscon-otghs = scm_conf 0x33c;
All other properties were of the format syscon-phy-foo.
Why use a different format here?
Ah, looks like we don't have a dedicated phy driver for this?
We will need to add a PHY driver I guess then and handle this register
in that driver rather than in the musb driver.
I was explaining in the other thread to Tony on why this shouldn't be done in
a
PHY driver [1].
And I just suggested thhere that it should be in the drivers/phy/phy-omap-usb2.c
PHY driver instead of the MUSB driver.
Regards,
Tony
[1] - https://lkml.org/lkml/2015/8/5/455
--
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 3/8] rtc: omap: Add external clock enabling support
* Alexandre Belloni alexandre.bell...@free-electrons.com [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;
clock-frequency = 32000;
clock-output-names = rtc_osc_xi_clkin32;
};
}
rtc {
status = okay;
clocks = sys_32k_ck, rtc_32k_ext_clk;
[optional] clock-names = int-clk, ext-clk;
};
Driver:
1) clk0 is mandatory, internal clock source
2) clk1 is optional, external clock source, so
if present - RTC driver can switch to use ext clock source
Absolutely!
Sounds good to me too.
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
[GIT PULL] omap dts changes for v4.3 merge window, part 3
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 to fetch changes up to ed05637c30e6d13e5793aab64d6a6e57e30228af: ARM: dts: omap3-devkit8000: Add ADS7846 Touchscreen support (2015-08-06 02:43:09 -0700) Omap device tree changes for v4.3 merge window. Pretty much all just trivial additions to configure devices for various SoCs and boards: - Updates for omap3-devkit8000 board support - M3 coprosessor, regulator, mux, RTC and eMMC updates for am437x - MMC, regmap, mux and dwc3 updates for dra7 and omap5 Anthoine Bourgeois (7): ARM: dts: omap3-devkit8000: Add user button support ARM: dts: omap3-devkit8000: Add PMU stat support ARM: dts: omap3-devkit8000: Add keymap support ARM: dts: omap3-devkit8000: Add S-video output support ARM: dts: omap3-devkit8000: Add DSS' DVI support ARM: dts: omap3-devkit8000: add LCD panels ARM: dts: omap3-devkit8000: Add ADS7846 Touchscreen support Balaji T K (1): ARM: dts: dra7-evm: add evm_3v3_sd regulator Dave Gerlach (2): ARM: dts: am43xx: Introduce MUX_MODE9 for pinctrl ARM: dts: am437x-gp-evm: Add regulator-always-on and regulator-boot-on for RTC DCDCs Felipe Balbi (1): ARM: dts: am4372: Add named interrupt property for dwc3 Keerthy (1): ARM: dts: AM4372: Reorder the rtc compatible string Kishon Vijay Abraham I (5): ARM: dts: dra72-evm: add evm_3v3_sd regulator ARM: dts: dra72-evm: Set max clock frequency of MMC1 and MMC2 ARM: dts: am57xx-beagle-x15: mmc1: remove redundant pbias-supply property ARM: dts: dra7-evm: Fix spurious card insert/removal interrupt ARM: dts: dra72-evm: Fix spurious card insert/removal interrupt Nishanth Menon (1): ARM: dts: dra7-evm: Add MMCSD card removal GPIO Roger Quadros (7): ARM: dts: omap5: Add named interrupt property for dwc3 ARM: dts: dra7: Add named interrupt property for dwc3 ARM: dts: dra7: Remove ctrl_core and ctrl_general nodes ARM: dts: dra7: fix pinmux@1400 resource length ARM: dts: dra7: Add scm_conf@1c04 node ARM: dts: am437x-gp-evm: Add gpio-hog for configuring eMMC/NAND driver ARM: dts: am437x-gp-evm: Add eMMC support Suman Anna (2): ARM: dts: AM33xx: Add the wkup_m3_ipc node ARM: dts: AM4372: Add the wkup_m3_ipc node arch/arm/boot/dts/Makefile | 2 + arch/arm/boot/dts/am33xx.dtsi | 8 + arch/arm/boot/dts/am4372.dtsi | 24 +- arch/arm/boot/dts/am437x-gp-evm.dts| 76 - arch/arm/boot/dts/am57xx-beagle-x15.dts| 1 - arch/arm/boot/dts/dra7-evm.dts | 18 +- arch/arm/boot/dts/dra7.dtsi| 38 ++- arch/arm/boot/dts/dra72-evm.dts| 16 +- arch/arm/boot/dts/dra74x.dtsi | 7 +- arch/arm/boot/dts/omap3-devkit8000-common.dtsi | 369 + arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi | 73 arch/arm/boot/dts/omap3-devkit8000-lcd43.dts | 37 +++ arch/arm/boot/dts/omap3-devkit8000-lcd70.dts | 37 +++ arch/arm/boot/dts/omap3-devkit8000.dts | 191 +-- arch/arm/boot/dts/omap5.dtsi | 7 +- include/dt-bindings/pinctrl/am43xx.h | 1 + 16 files changed, 695 insertions(+), 210 deletions(-) create mode 100644 arch/arm/boot/dts/omap3-devkit8000-common.dtsi create mode 100644 arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi create mode 100644 arch/arm/boot/dts/omap3-devkit8000-lcd43.dts create mode 100644 arch/arm/boot/dts/omap3-devkit8000-lcd70.dts -- 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 3/8] rtc: omap: Add external clock enabling support
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 there was a concern on the external clock not being present i added a board dts flag. So you mean this external clock is coming internally from the SoC? No what i meant is external clock is coming from Oscillator OSC1 @32.768KHz but the controlling bits are part of rtc register space. TRM: http://www.ti.com/lit/ug/spruhl7c/spruhl7c.pdf Section: 19.4.3.2 Clock Source Page 2836 Also register details: 19.4.5.19 RTCSS_OSC_REG Register (offset = 54h) [reset = 10h] Page 2865. This confirms what I'm saying. Your issue here is that the driver is not properly taking the clocks so when the PRCM is disabling CLK_32KHZ, you end up without any clock. You can use the clocks property in the device tree and pass two clocks, the prcm one and the external crystal/external oscillator. In the driver, you get both clock, clk_get_rate on the external one will help you know whether it is populated or not (this will be 0 or 32768). It is is populated, use it by writing 32KCLK_SEL. Bonus points if you use the clock-accuracy and decide to switch between PRCM and the external clock when going to suspend and resuming. I guess an external RC oscillator is quite bad versus the PRCM. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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 3/8] rtc: omap: Add external clock enabling support
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;
clock-output-names = rtc_osc_xi_clkin32;
};
}
rtc {
status = okay;
clocks = sys_32k_ck, rtc_32k_ext_clk;
[optional] clock-names = int-clk, ext-clk;
};
Driver:
1) clk0 is mandatory, internal clock source
2) clk1 is optional, external clock source, so
if present - RTC driver can switch to use ext clock source
Absolutely!
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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 1/2] regulator: pbias: use untranslated address to program pbias regulator
On 08/06/2015 09:26 AM, Tony Lindgren wrote: * Kishon Vijay Abraham I kis...@ti.com [150805 07:59]: Hi Tony, On Wednesday 05 August 2015 03:17 PM, Tony Lindgren wrote: * Kishon Vijay Abraham I kis...@ti.com [150727 04:27]: vsel_reg and enable_reg of the pbias regulator descriptor should actually have the offset from syscon. However after the pbias device tree node is moved as a child node of syscon, vsel_reg and enable_reg has the absolute address because of the address translation that happens while creating device from device tree node. So avoid using platform_get_resource and use of_get_address in order to get only the offset (untranslated address) and populate these in vsel_reg and enable_reg. I think this gets fixed automatically with your other series adding the simple-bus to the nodes. For the children of_ioremap Nope. The probe of pbias regulator fails as Grygorii has already pointed out here [1]. Oh I see, you want the offset from syscon, not the virtual address of the register. Yeah then it makes sense to me. You could also get the offset by doing res-start 0xff or something but I don't know if that's any better. I guess ideallly we'd have some syscon function to get the offest from the syscon base if it does not exist already. Hypothetically, the syscon property can be used to get register offset syscon = scm_conf 0xe00; and even reg property can be dropped if driver uses syscon/regmap only for io. But, in this particular case, such change will lead to DT compatibility issues :( -- regards, -grygorii -- 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: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
On 6 August 2015 at 11:02, Mark Brown broo...@kernel.org wrote: On Wed, Aug 05, 2015 at 02:56:09PM +0200, Michal Suchanek wrote: On 5 August 2015 at 14:44, Mark Brown broo...@kernel.org 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 detection that we are talking to a SPI flash memory. Why care - if something is physically in the same format as a flash read command how would a device be able to tell that it wasn't actually a flash read command? The signals sent on the bus are going to be identical anyway. Not only must the command be the same but also the response must be tha same. What difference would that make? The caller is sending a single SPI operation and this is a user visible thing... The flash chip responds by sending arbitrary amount of data. Given that transfer_one gets only the part that sends the read command and the part to do the actual read may or may not follow this is getting a bit hairy. Add in dummy bytes due to fast-read lag and page write wrap-around and you get something that you definitely do not want unless you are really sure that there is a flash memory on the other end of the wire. So if you're doing this you may have a good reason to implement transfer_one_message() instead. Or perhaps implement it in the core and provide operations to do the map and unmap. And of course if this sort of requirement exists that's an obvious thing that must be documented in the interfaces but isn't. We need a lot more thought about the interface here, the lack of any explanation of what the interface is supposed to be and the fact that all questions about it are being answered in terms of describing the specific system are both a bit worrying. 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 is set. If I was using m25p80.c to talk to anything but an actual flash chip it would get me quite worried. Thanks Michal -- 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: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
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 is set. That, to me, sounds like what you have is: ---m25p80 specific interface---SPI bus---m25p80 device Where the m25p80 specific interface does not expose direct access to the SPI bus? 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 high-level like: +---+ | m25p80 high-level driver | +--++ | SPI m25p80 driver || +--+| | SPI layer | Special driver| +--+| |SPI bus driver|| +--++ | SPI hardware | Special hardware | +--++ Rather than what you seem to be trying to do, which seems to be: +--+ | SPI m25p80 driver | +--+ | SPI layer | +--+ | Translation driver | +--+ | Special hardware | +--+ where this requires M25P80 specific hacks to be introduced into the SPI layer so that you can communicate additional information between the SPI M25P80 driver and the translation driver. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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
[GIT PULL] omap pbias regulator regression fixes against v4.2-rc5
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-for-v4.2/fixes-rc5 for you to fetch changes up to cd4556733b30cc363adc7b1cea3bffa7e2dd0c7c: ARM: dts: dra7: Fix broken pbias device creation (2015-08-05 03:04:07 -0700) Few trivial omap MMC regression fixes for card voltages where the syscon areas for PBIAS regulator were missing simple-bus that prevents probing of the children in the mapped region. This probably was not noticed earlier as the bootloader has already configured the regulator for the card in the slot. Kishon Vijay Abraham I (4): ARM: dts: omap243x: Fix broken pbias device creation ARM: dts: OMAP4: Fix broken pbias device creation ARM: dts: OMAP5: Fix broken pbias device creation ARM: dts: dra7: Fix broken pbias device creation arch/arm/boot/dts/dra7.dtsi | 2 +- arch/arm/boot/dts/omap2430.dtsi | 3 ++- arch/arm/boot/dts/omap4.dtsi| 3 ++- arch/arm/boot/dts/omap5.dtsi| 3 ++- 4 files changed, 7 insertions(+), 4 deletions(-) -- 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 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle
* Suman Anna s-a...@ti.com [150805 08:35]: Hi Tony, On 08/05/2015 05:28 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [150717 13:59]: --- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt +++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt @@ -75,6 +75,14 @@ data that represent the following: Cell #3 (usr_id) - mailbox user id for identifying the interrupt line associated with generating a tx/rx fifo interrupt. +Optional Properties: + +- ti,mbox-send-noirq: Quirk flag to allow the client user of this sub-mailbox +to send messages without triggering a Tx ready interrupt, +and to control the Tx ticker. Should be used only on +sub-mailboxes used to communicate with WkupM3 remote +processor on AM33xx/AM43xx SoCs. + Hmm can't you do this just by setting a flag in the device driver based on the compatible string? We can't because there can be other users like PRUSS which will use a sub-mailbox in a regular fashion. The compatible serves the IP and there can be multiple sub-mailboxes underneath it, and this quirk is needed only on the one that's used by the WkupM3. OK Do you have any comments on this? Up to you guys then to figure out what property is used for it then. 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: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
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 high-level like: +---+ | m25p80 high-level driver | +--++ | SPI m25p80 driver || +--+| | SPI layer | Special driver| +--+| |SPI bus driver|| +--++ | SPI hardware | Special hardware | +--++ Yes, that's what's been talked about before - for some of these devices they're sufficiently flash specialist that we just don't bother exposing a SPI interface at all though AIUI they could be persuaded to do it. It isn't entirely clear that we want exactly that split, if the devices are reasonable SPI controllers we will want to handle the case where they have flash and non-flash devices on the same bus. For that there is going to be some generalisable work possible for managing switching between memory mapped and SPI modes where those are mutually exclusive, especially if the switch between them isn't free. signature.asc Description: Digital signature
Re: [PATCH 07/13] twl4030_charger: distinguish between USB current and 'AC' current
* NeilBrown n...@brown.name [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;
bool cgain = false;
u8 boot_bci;
+ /*
+ * If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
+ * and AC is enabled, set current for 'ac'
+ */
+ if (twl4030_get_madc_conversion(11) 4500) {
+ cur = bci-ac_cur;
+ bci-ac_is_active = true;
+ } else {
+ cur = bci-usb_cur;
+ bci-ac_is_active = false;
+ }
+
/* First, check thresholds and see if cgain is needed */
if (bci-ichg_eoc = 20)
cgain = true;
Neil, you need a stub or something for twl4030_get_madc_conversion
if madc is not selected. Now at least omap2plus_defconfig and
ARM allmodconfig fails in Linux next.
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: [PATCH 07/13] twl4030_charger: distinguish between USB current and 'AC' current
* NeilBrown n...@brown.name [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 thanks: Acked-by: Tony Lindgren t...@atomide.com -- 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 07/13] twl4030_charger: distinguish between USB current and 'AC' current
On Fri, 7 Aug 2015 07:13:09 +0200 Sebastian Reichel s...@kernel.org 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 below patch with Tony's ACK to fix the build issue in next. OK, thanks. I'll try to figure out are more proper approach ... might be a week or so though. Thanks, NeilBrown pgpEQ176T2qUB.pgp Description: OpenPGP digital signature
cmm files for omap4460
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: 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
[PATCH 1/1] ARM: OMAP2+: Fix power domain operations regression caused by 81xx
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 mode any longer
causing idle power consumption go up from less than 10mW to over
50 mW.
Fixs: 7c80a3f89c51 (ARM: OMAP2+: Add custom prwdm_operations for
81xx to support dm814x)
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/powerdomains3xxx_data.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
@@ -580,7 +580,9 @@ void __init omap3xxx_powerdomains_init(void)
if (!cpu_is_omap34xx() !cpu_is_ti81xx())
return;
- pwrdm_register_platform_funcs(ti81xx_pwrdm_operations);
+ /* Only 81xx needs custom pwrdm_operations */
+ if (!cpu_is_ti81xx())
+ pwrdm_register_platform_funcs(omap3_pwrdm_operations);;
rev = omap_rev();
@@ -588,9 +590,11 @@ void __init omap3xxx_powerdomains_init(void)
pwrdm_register_pwrdms(powerdomains_am35x);
} else if (rev == TI8148_REV_ES1_0 || rev == TI8148_REV_ES2_0 ||
rev == TI8148_REV_ES2_1) {
+ pwrdm_register_platform_funcs(ti81xx_pwrdm_operations);
pwrdm_register_pwrdms(powerdomains_ti814x);
} else if (rev == TI8168_REV_ES1_0 || rev == TI8168_REV_ES1_1
|| rev == TI8168_REV_ES2_0 || rev == TI8168_REV_ES2_1) {
+ pwrdm_register_platform_funcs(ti81xx_pwrdm_operations);
pwrdm_register_pwrdms(powerdomains_ti816x);
} else {
pwrdm_register_pwrdms(powerdomains_omap3430_common);
--
2.1.4
--
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 1/8] ARM: dts: AM4372: Reorder the rtc compatible string
* Keerthy a0393...@ti.com [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 that's needed :) 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: [4.2-rc1][PATCH] gpio: omap: add missed spin_unlock_irqrestore in omap_gpio_irq_type
* Linus Walleij linus.wall...@linaro.org [150716 01:38]:
On Wed, Jun 24, 2015 at 4:54 PM, Grygorii Strashko
grygorii.stras...@ti.com wrote:
From: Grygorii Strashko grygorii.stras...@linaro.org
Add missed spin_unlock_irqrestore in omap_gpio_irq_type when
omap_set_gpio_triggering() is failed.
It fixes static checker warning:
drivers/gpio/gpio-omap.c:523 omap_gpio_irq_type()
warn: inconsistent returns 'spin_lock:bank-lock'.
This fixes commit:
1562e4618ded ('gpio: omap: fix error handling in omap_gpio_irq_type')
Reported-by: Javier Martinez Canillas jav...@dowhile0.org
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
Patch applied for fixes.
Linus, looks like we now have a new build warning in Linux next
with the fixes and raw_spinlock_t change, so a merge or a commit
is needed. If you prefer a patch, here's one below.
Regards,
Tony
8 ---
From: Tony Lindgren t...@atomide.com
Date: Thu, 6 Aug 2015 20:32:24 -0700
Subject: [PATCH] gpio: omap: Fix build warning for raw_spinlock_t conversion
and unlock fix
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Looks like we now have a new build warning in Linux next with fix
977bd8a94c40 (gpio: omap: add missed spin_unlock_irqrestore in
omap_gpio_irq_type) and raw_spinlock changes done in commit
4dbada2be460 (gpio: omap: use raw locks for locking):
drivers/gpio/gpio-omap.c: In function ‘omap_gpio_irq_type’:
drivers/gpio/gpio-omap.c:504:26: warning: passing argument 1 of
‘spin_unlock_irqrestore’ from incompatible pointer type
[-Wincompatible-pointer-types]
spin_unlock_irqrestore(bank-lock, flags);
^
In file included from include/linux/seqlock.h:35:0,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from drivers/gpio/gpio-omap.c:16:
include/linux/spinlock.h:370:122: note: expected
‘spinlock_t * {aka struct spinlock *}’ but argument is of type
‘raw_spinlock_t * {aka struct raw_spinlock *}’
Fix the issue with using raw_spinlock_t instead.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -501,7 +501,7 @@ static int omap_gpio_irq_type(struct irq_data *d, unsigned
type)
raw_spin_lock_irqsave(bank-lock, flags);
retval = omap_set_gpio_triggering(bank, offset, type);
if (retval) {
- spin_unlock_irqrestore(bank-lock, flags);
+ raw_spin_unlock_irqrestore(bank-lock, flags);
goto error;
}
omap_gpio_init_irq(bank, offset);
--
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 07/13] twl4030_charger: distinguish between USB current and 'AC' current
On Thu, 6 Aug 2015 20:11:16 -0700 Tony Lindgren t...@atomide.com
wrote:
* NeilBrown n...@brown.name [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;
bool cgain = false;
u8 boot_bci;
+ /*
+* If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
+* and AC is enabled, set current for 'ac'
+*/
+ if (twl4030_get_madc_conversion(11) 4500) {
+ cur = bci-ac_cur;
+ bci-ac_is_active = true;
+ } else {
+ cur = bci-usb_cur;
+ bci-ac_is_active = false;
+ }
+
/* First, check thresholds and see if cgain is needed */
if (bci-ichg_eoc = 20)
cgain = true;
Neil, you need a stub or something for twl4030_get_madc_conversion
if madc is not selected. Now at least omap2plus_defconfig and
ARM allmodconfig fails in Linux next.
Regards,
Tony
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?
Thanks,
NeilBrown
From: NeilBrown n...@brown.name
Date: Fri, 7 Aug 2015 13:44:37 +1000
Subject: [PATCH] twl4030_charger: fix compile error when TWL4030_MADC not
available.
We can only use the madc to check for 'ac' availability
if the madc has been compiled in.
If not: assume always using USB.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: NeilBrown n...@brown.name
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index c7432f532a83..265fd236f4c0 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -91,6 +91,21 @@
#define TWL4030_MSTATEC_COMPLETE1 0x0b
#define TWL4030_MSTATEC_COMPLETE4 0x0e
+#if IS_ENABLED(CONFIG_TWL4030_MADC)
+/*
+ * If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
+ * then AC is available.
+ */
+static inline int ac_available(void)
+{
+ return twl4030_get_madc_conversion(11) 4500;
+}
+#else
+static inline int ac_available(void)
+{
+ return 0;
+}
+#endif
static bool allow_usb;
module_param(allow_usb, bool, 0644);
MODULE_PARM_DESC(allow_usb, Allow USB charge drawing default current);
@@ -263,7 +278,7 @@ static int twl4030_charger_update_current(struct
twl4030_bci *bci)
* If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
* and AC is enabled, set current for 'ac'
*/
- if (twl4030_get_madc_conversion(11) 4500) {
+ if (ac_available()) {
cur = bci-ac_cur;
bci-ac_is_active = true;
} else {
--
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 07/13] twl4030_charger: distinguish between USB current and 'AC' current
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, 2015 at 01:45:25PM +1000, NeilBrown wrote:
From: NeilBrown n...@brown.name
Date: Fri, 7 Aug 2015 13:44:37 +1000
Subject: [PATCH] twl4030_charger: fix compile error when TWL4030_MADC not
available.
We can only use the madc to check for 'ac' availability
if the madc has been compiled in.
If not: assume always using USB.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: NeilBrown n...@brown.name
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index c7432f532a83..265fd236f4c0 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -91,6 +91,21 @@
#define TWL4030_MSTATEC_COMPLETE10x0b
#define TWL4030_MSTATEC_COMPLETE40x0e
+#if IS_ENABLED(CONFIG_TWL4030_MADC)
+/*
+ * If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
+ * then AC is available.
+ */
+static inline int ac_available(void)
+{
+ return twl4030_get_madc_conversion(11) 4500;
+}
+#else
+static inline int ac_available(void)
+{
+ return 0;
+}
+#endif
static bool allow_usb;
module_param(allow_usb, bool, 0644);
MODULE_PARM_DESC(allow_usb, Allow USB charge drawing default current);
@@ -263,7 +278,7 @@ static int twl4030_charger_update_current(struct
twl4030_bci *bci)
* If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
* and AC is enabled, set current for 'ac'
*/
- if (twl4030_get_madc_conversion(11) 4500) {
+ if (ac_available()) {
cur = bci-ac_cur;
bci-ac_is_active = true;
} else {
-- Sebastian
signature.asc
Description: Digital signature
[PATCH] ARM: dts: AM4372: Add the am4372-rtc compatible string
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 j-keer...@ti.com
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt | 1 +
arch/arm/boot/dts/am4372.dtsi | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index 4ba4dbd..43a8366 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -8,6 +8,7 @@ Required properties:
Wakeup generation for event Alarm. It can also be
used to control an external PMIC via the
pmic_power_en pin.
+ - ti,am4372-rtc - for RTC IP used similar to that on AM437X SoC
family.
- reg: Address range of rtc register set
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 65c4334..d99b2ee 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -330,7 +330,8 @@
};
rtc: rtc@44e3e000 {
- compatible = ti,am3352-rtc, ti,da830-rtc;
+ compatible = ti,am4372-rtc, ti,am3352-rtc,
+ti,da830-rtc;
reg = 0x44e3e000 0x1000;
interrupts = GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH;
--
1.9.1
--
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 3/3] serial: 8250: omap: restore registers on shutdown
On Fri, Aug 7, 2015 at 6:22 AM, Peter Hurley pe...@hurleysoftware.com 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 kernel. I have a 1Mbaud link that is getting packets of about 22 bytes @800 Hz and old omap-serial is keeping up, but killing the CPU. I'm considering backporting 8250_omap as a get out of jail. Opinions appreciated. Thanks. -- 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 1/2] regulator: pbias: use untranslated address to program pbias regulator
* Kishon Vijay Abraham I kis...@ti.com [150805 07:59]: Hi Tony, On Wednesday 05 August 2015 03:17 PM, Tony Lindgren wrote: * Kishon Vijay Abraham I kis...@ti.com [150727 04:27]: vsel_reg and enable_reg of the pbias regulator descriptor should actually have the offset from syscon. However after the pbias device tree node is moved as a child node of syscon, vsel_reg and enable_reg has the absolute address because of the address translation that happens while creating device from device tree node. So avoid using platform_get_resource and use of_get_address in order to get only the offset (untranslated address) and populate these in vsel_reg and enable_reg. I think this gets fixed automatically with your other series adding the simple-bus to the nodes. For the children of_ioremap Nope. The probe of pbias regulator fails as Grygorii has already pointed out here [1]. Oh I see, you want the offset from syscon, not the virtual address of the register. Yeah then it makes sense to me. You could also get the offset by doing res-start 0xff or something but I don't know if that's any better. I guess ideallly we'd have some syscon function to get the offest from the syscon base if it does not exist already. Regards, Tony [1] - http://www.spinics.net/lists/linux-omap/msg120462.html -- 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: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
On 6 August 2015 at 13:23, Mark Brown broo...@kernel.org 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 terms is that supposed to mean? It's currently just an essentially undocumented flag on a message rather than something operating at the level of a flash chip. That's pretty much where Russell's comments come from. If I was using m25p80.c to talk to anything but an actual flash chip it would get me quite worried. 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 bother with the flag, we can just pattern match on the format of the message. If that doesn't work then probably this isn't a great interface and a separate, application specific interface makes more sense. The messages are sensible interface for communicating with a device that interprets a particular part of the mesasge as address and another particular part of the message as command and sends same amount of junk before reply as the flash chip would. If your device happens to send reply immediately part of it is trashed. If it happens to interpret address differently the data ends up in random part of your memory. So no, that is not something you can autodetect. At the end of the day you have valid SPI messages but the m25p80 layer adds interpretation to those messages which may not always give correct result. On the other hand, if you ever get to m25p80 or spi-nor you can assume any message you send goes to a flash chip and insist that the controller uses the flash-specific interface. If there is possibility of connecting different kind of devices to multiple chipselects on the same master then you probably want to select this option per message or per slave. Thanks Michal -- 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: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
On 6 August 2015 at 12:22, Russell King - ARM Linux li...@arm.linux.org.uk 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 basically supposed to implement m25p80.c in hardware when this flag is set. That, to me, sounds like what you have is: ---m25p80 specific interface---SPI bus---m25p80 device Where the m25p80 specific interface does not expose direct access to the SPI bus? The m25p80 specific hardware interface is presumably optional so you can use it or not. The description is a bit vague, though. In fsl-qspi the driver does not make it optional. I am not sure that controller can be used for non-m25p80 slaves. 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 high-level like: +---+ | m25p80 high-level driver =spi-nor | +--++ | SPI m25p80 driver || +--+| | SPI layer | Special driver=fsl-qspi| +--+| |SPI bus driver|| +--++ | SPI hardware | Special hardware | +--++ Thanks Michal -- 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
[GIT PULL] omap clock dts changes for v4.3 merge window
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: ARM: dts: am4372: Set the default clock rate for dpll_clksel_mac_clk clock (2015-07-31 12:13:18 +0300) Keerthy (2): ARM: dts: AM437X: add dpll_clksel_mac_clk node ARM: dts: am4372: Set the default clock rate for dpll_clksel_mac_clk clock arch/arm/boot/dts/am4372.dtsi|7 +-- arch/arm/boot/dts/am43xx-clocks.dtsi |9 + drivers/clk/ti/clk-43xx.c|1 + 3 files changed, 15 insertions(+), 2 deletions(-) -- 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: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
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 basically supposed to implement m25p80.c in hardware when this flag is set. That, to me, sounds like what you have is: ---m25p80 specific interface---SPI bus---m25p80 device Where the m25p80 specific interface does not expose direct access to the SPI bus? Let me give overview of ti-qspi controller: There are two interfaces in the controller, one exposes direct access to SPI bus and the other doesn't. It is possible to dynamically switch between these ports by writing to QSPI_SPI_SWITCH_REG. The two interface are [1]: 1) Generic SPI interface: (config port): with this interface, ti-qspi controller can communicate with *any* spi device (flash and non-flash). This interface is provides direct access to SPI bus. 2) SPI memory mapped interface (memory mapped port): This is m25p80 specific interface which can be use to read data from flash. But if the flash has to be configured to some particular mode like QUAD READ MODE, then the controller needs to be put in to config port to read and modify serial flash's config register and then switch to memory mapped port in order to read data stored on flash. For example on DRA74 evm, if a 64 MB flash is connected as a slave, entire flash memory is visible from 0x5C00 to 0x5FFF L3_MAIN address. In order to read using memory mapped port following will be the sequence: 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. 3. Switch to memory mapped port by writing to QSPI_SPI_SWITCH_REG. 4. Now, its possible to perform read from 0x5C00 to 0x5FFF using memcpy. The qspi controller hardware will communicate over SPI bus and get the data. This data is directly sent to RAM via SoC's interconnect. Advantages of memory mapped port are: improved read performance, MEM_TO_MEM DMA support can be added (ti-qspi hardware as such does not provide DMA events). Advantages of config port: can be used to communicate with *any* SPI device, provides direct read/write access to SPI bus. 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 bus directly. 2. take advantage of memory mapped port in order to increase read throughput( and use dma in future) when the slave is a m25p80 type flash. 3. handle m25p80 as well as other slave on multiple chipselects. I just need to know whether the user that requested the transfer is m25p80 driver. If yes, ti-qspi driver can take advantage of memory mapped interface, else just use config port to access SPI bus directly. Writing separate driver based on spi-nor framework to interface with m25p80 is not an option because, I would lose the ability to interface with non-flash devices. The spi_message that is received in transfer_one_message() is too generic to imply the slave device that is on the other side of the wire. IMO, the read command does not imply that the slave is m25p80 flash (besides the read opcodes vary across vendors of m25p80 and across modes). As Michal suggested, adding a flag to spi_device to distinguish whether the slave is a m25p80 flash type will help spi master to handle optimizations specific to m25p80s while being generic enough to handle all other spi devices. Is that ok? Is there any other way to imply what slave as at the other end? [1] TRM: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf 24.5.4 QSPI Functional Description -- 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 3/3] serial: 8250: omap: restore registers on shutdown
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 the dma struct instead of keeping in the omap specific part. I am also not sure if OMAP is the only one that may hang here or the other people just didn't notice it yet. Exactly; and we need to fix DMA wrt x_char anyway. Going back to the dmaengine api, I think something like this might work (as a first approximation): dma_sync_wait(dma-txchan, dma-tx_cookie); dmaengine_pause(dma-txchan); /* remainder of set_termios */ dmaengine_resume(dma-txchan); We could require 8250 core dma to support pause/resume. I would prefer the waitqueue approach. You can't do this while holding the port lock. The lock is taken with irqs off so may not see the transfer completing. Why do you pause the channel? It may not work without an active descriptor and a start without resume should work. Also you must ensure that DMA's complete callback does not start another transfer if there is something queued up (that is why I had the tx_running dance). I am not sure if a transfer that is active and then paused will not trigger the hang bug if we change the termios in between. I'll look at/test this this weekend, ok? Regards, Peter Hurley -- 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: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
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 essentially undocumented flag on a message rather than something operating at the level of a flash chip. That's pretty much where Russell's comments come from. If I was using m25p80.c to talk to anything but an actual flash chip it would get me quite worried. 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 bother with the flag, we can just pattern match on the format of the message. If that doesn't work then probably this isn't a great interface and a separate, application specific interface makes more sense. signature.asc Description: Digital signature
Re: [PATCH 3/3] serial: 8250: omap: restore registers on shutdown
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 the callback? That way I could move the termios_wait into the dma struct instead of keeping in the omap specific part. I am also not sure if OMAP is the only one that may hang here or the other people just didn't notice it yet. Exactly; and we need to fix DMA wrt x_char anyway. Going back to the dmaengine api, I think something like this might work (as a first approximation): dma_sync_wait(dma-txchan, dma-tx_cookie); dmaengine_pause(dma-txchan); /* remainder of set_termios */ dmaengine_resume(dma-txchan); We could require 8250 core dma to support pause/resume. I would prefer the waitqueue approach. You can't do this while holding the port lock. The lock is taken with irqs off so may not see the transfer completing. Why do you pause the channel? It may not work without an active descriptor and a start without resume should work. Also you must ensure that DMA's complete callback does not start another transfer if there is something queued up (that is why I had the tx_running dance). I am not sure if a transfer that is active and then paused will not trigger the hang bug if we change the termios in between. 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. Regards, Peter Hurley Sebastian -- 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: next-20150806 build: 2 failures 52 warnings (next-20150806)
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_vprint/seq_printf/etc... returns to void) which made seq_printf() return void and e203db293863fa15 (iommu/omap: Fix debug_read_tlb() to use seq_printf()) which has been in -next for a little while now. signature.asc Description: Digital signature
Re: [PATCH 1/8] ARM: dts: AM4372: Reorder the rtc compatible string
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 Wed, Aug 05, 2015 at 09:21:05PM +0530, Keerthy wrote: Felipe, On Wednesday 05 August 2015 09:01 PM, Felipe Balbi wrote: On Wed, Aug 05, 2015 at 04:19:45PM +0530, Keerthy wrote: Compared to da830-rtc compatibility am3352-rtc is more compatible to the one in am437x. Hence adding the am3352-rtc compatible to cover the entire feature set. The ti,am4372-rtc has no Documentation and not used even in the driver hence removing it. why don't you do the inverse ? Document am4372-rtc and make driver use it ? am3352-rtc suffices for am4372 too. No need to add additional one for am4372. Until we end up needing it, right ? :-) Besides, it's already used in a DTS. What happens if someone branched from that DTS and ships that in a product. RTC will just stop working 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. BTW, this compatible has been in tree since August 2013, IMO it's unfar to drop it just like that. Documenting it would be a better approach. Okay. Can you point me to a file which is already accessing it in dts? Accessing what ? Also, once DTS reaches a major kernel release, it's deemed stable and should be supported. Are we dropping that ? I meant getting used in any other dts files than the one i just dropped it. how can you ever know that for sure ? There are already quite a few third party platforms based on AM437x, how can you be sure those companies don't have their own DTS ? Felipe, If that is a concern i can re-do this. Tony, 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. Regards, Keerthy -- 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
[PATCH 1/2] OMAPDSS: dss-of: Fix node refcount leak in omapdss_of_get_next_port()
Signed-off-by: Jyri Sarha jsa...@ti.com --- 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/fbdev/omap2/dss/dss-of.c @@ -60,6 +60,7 @@ omapdss_of_get_next_port(const struct device_node *parent, } prev = port; } while (of_node_cmp(port-name, port) != 0); + of_node_put(ports); } return port; -- 1.9.1 -- 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
[PATCH 0/2] OMAPDSS: Fix of-node refcount issues
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_*() functions are quite different from omapdss_of_*() counterparts. So it better to just fix these bugs first. Jyri Sarha (2): OMAPDSS: dss-of: Fix node refcount leak in omapdss_of_get_next_port() OMAPDSS: of-dss: omap_dss_find_output_by_port_node() keep port refcount drivers/video/fbdev/omap2/dss/dss-of.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.9.1 -- 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 3/3] serial: 8250: omap: restore registers on shutdown
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 at x_char. So now that I actually look at it. If I read this right, we never send the x_char if the TX-DMA never fails to do its job. That's what I saw too; almost all the dma drivers are broken wrt x_char. The amba-pl011 driver gets it right. The comment above uart_send_xchar() says it is high priority. 'High' priority is meant relative to previously written data which has not yet been sent. What do you suggest, wait until the transfer completes, send the x_char _or_ pause the transfer send that byte and then send the byte? 'Better' would be sending the x_char when the current dma transfer completes. However, it will probably have /some/ impact on what line rates software flow control can be used. Worst case @ 115Kbaud is 35ms delay in sending. 'Best' would be pausing the dma and sending the byte. However, I'm not even sure if this is possible on OMAP; the TRM is woefully under-documented in that regard. In both cases we have to wait until for the FIFO-empty interrupt to make sure we don't overrun that TX-FIFO. I *think* waiting until the transfer completes would be simpler but it is not necessarily high priority. I agree; this is what we should do first because someone might want it for backports. Regards, Peter Hurley -- 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: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
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 number of bytes */ dummy /= 8; flash-command[0] = nor-read_opcode; m25p_addr2cmd(nor, from, flash-command); t[0].tx_buf = flash-command; t[0].len = m25p_cmdsz(nor) + dummy; spi_message_add_tail(t[0], m); The reason that the number of dummy bytes can't be detected is because it's all hidden in the first transaction as the total number of bytes to be transmitted - and the dummy bytes are uninitialised, so you can't make any assumptions what value they are. There is no way for the SPI driver to know whether these dummy bytes are dummy bytes or whether they have an effect on the targetted device. We *could* (as you suggest below) indicate dummy transfers by having a separate transfer which omits the transmit buffers though I'd expect that normally that is going to be a small performance hit if interpreted directly so we need to think what to do there. We do get other devices sending dummy bytes, it's sometimes a requirement for high speed register access to give settling time for the device, so other things would get some milage from it. What may make more sense from the SPI point of view is to communicate to all SPI drivers how many dummy bytes are to be transferred. I'm not fully up on SPI, but maybe something like this: t[0].tx_buf = flash-command; t[0].len = m25p_cmdsz(nor); spi_message_add_tail(t[0], m); t[1].tx_buf = dummy_buffer; t[1].len = dummy; t[1].dummy = 1; spi_message_add_tail(t[1], m); This way, we're describing the transfer to the SPI core, and explicitly indicating that there are some dummy bytes. The SPI driver can then tell that these are dummy bytes, and if the SPI message consists of: That'd work as well, my first thought would to use NULL as a dummy buffer pointer and let the core substitute in data for the drivers. We currently insist on having at least one buffer but that's fixable. This would not be a hack to the SPI code: we're describing to the SPI code what we want to achieve in terms of the activity on the bus, and providing that level of description then allows the SPI driver to make informed decisions on whether it can handle the transfer using some non-standard feature. Yup. signature.asc Description: Digital signature
Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
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 things being constant for a given flash? 3. Switch to memory mapped port by writing to QSPI_SPI_SWITCH_REG. 4. Now, its possible to perform read from 0x5C00 to 0x5FFF using memcpy. The qspi controller hardware will communicate over SPI bus and get the data. This data is directly sent to RAM via SoC's interconnect. Presumably if it's done via memcpy() it won't go direct to RAM but rather be bounced through the CPU which is a bit interesting for performance (it might help, but it does mean that there's a core stalled waiting for the flash which might not be the best use of resources if there's other things it can be getting on with). With DMA it'd be a direct to memory transfer though. Advantages of memory mapped port are: improved read performance, MEM_TO_MEM DMA support can be added (ti-qspi hardware as such does not provide DMA events). DMA would definitely help here. I just need to know whether the user that requested the transfer is m25p80 driver. If yes, ti-qspi driver can take advantage of memory mapped interface, else just use config port to access SPI bus directly. You don't *really* care if it's that specific user so much as that it's that particular pattern. Writing separate driver based on spi-nor framework to interface with m25p80 is not an option because, I would lose the ability to interface with non-flash devices. You could, however, expose an explicit flash mapping interface for this functionality. That does seem like it's going to be an awful lot easier and help with keeping things like DMA support out of the driver and in the core (which would be useful if there's other controllers with the same functionality, I seem to recall that there are). The spi_message that is received in transfer_one_message() is too generic to imply the slave device that is on the other side of the wire. IMO, the read command does not imply that the slave is m25p80 flash (besides the read opcodes vary across vendors of m25p80 and across modes). Again, it doesn't matter if it's actually a read command only that it's got a compatible format on the bus. signature.asc Description: Digital signature
Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
On 6 August 2015 at 18:14, Geert Uytterhoeven ge...@linux-m68k.org wrote: On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux li...@arm.linux.org.uk 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 driver, I dont want to break it). Or pump any spi_message on to SPI bus directly. 2. take advantage of memory mapped port in order to increase read throughput( and use dma in future) when the slave is a m25p80 type flash. 3. handle m25p80 as well as other slave on multiple chipselects. I just need to know whether the user that requested the transfer is m25p80 driver. If yes, ti-qspi driver can take advantage of memory mapped interface, else just use config port to access SPI bus directly. The problem with this approach is that it's an abomination. It's adding a SPI-user specific hack which is detected by a specific driver. That's really not sane - what happens when we have lots of these kinds of I'm an X SPI-user with drivers detecting that? It's not maintainable in the long term. Yes, your requirements _today_ seem simple and easy, but you're only thinking about today, not tomorrow when you've moved on and someone else has to maintain the mess left behind (or delete it from mainline because they're sick of dealing with a hack.) The spi_message that is received in transfer_one_message() is too generic to imply the slave device that is on the other side of the wire. IMO, the read command does not imply that the slave is m25p80 flash (besides the read opcodes vary across vendors of m25p80 and across modes). I can see both sides of the argument. Mark is saying: if the SPI driver detects that the message to be transmitted is a read command followed by the appropriate number of dummy bytes, and then the data being read _and_ it's using quad-mode access, and the hardware generates _exactly_ that in hardware using the memory mapped mode, there is no reason _not_ to use the hardware to achieve that SPI transaction. The bus activity will be identical to what happens when the SPI controller is used manually to achieve that bus sequence. You're saying: but the documentation says you can't use it for anything except m25p80. If you look at 24.5.4.1.2, it tells you what the SFI generates on the bus, which is: 1. CS active 2. Read command byte sent 3. 1-4 address bytes sent 4. 0-3 dummy bytes sent 5. data bytes read from bus 6. CS inactive So, Mark's point is if we can detect a transaction which fits _that_ bus activity, there's no reason not to use this acceleration for the transaction. What you're failing to counter with is: we don't have enough information in the SPI driver to know how many dummy bytes there are between the address bytes and the data read from the bus. Irrespective of the dummy bytes. What if the spi device is not a FLASH ROM, but some other device, which receives a data packet that accidentally looks like an m25p80 READ command? Presumably the driver would interpret some random part of the message as address and map the reply in your address space at that address from the flash mmap base. If you happen to overflow the flash memory mmap space the behaviour will probably not be well defined. Thanks Michal -- 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
[PATCH 2/2] OMAPDSS: of-dss: omap_dss_find_output_by_port_node() keep port refcount
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 jsa...@ti.com
---
drivers/video/fbdev/omap2/dss/dss-of.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss-of.c
b/drivers/video/fbdev/omap2/dss/dss-of.c
index ab6ef16..43f999d 100644
--- a/drivers/video/fbdev/omap2/dss/dss-of.c
+++ b/drivers/video/fbdev/omap2/dss/dss-of.c
@@ -95,7 +95,7 @@ struct device_node *dss_of_port_get_parent_device(struct
device_node *port)
if (!port)
return NULL;
- np = of_get_next_parent(port);
+ np = of_get_parent(port);
for (i = 0; i 2 np; ++i) {
struct property *prop;
--
1.9.1
--
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: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
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 bus directly. 2. take advantage of memory mapped port in order to increase read throughput( and use dma in future) when the slave is a m25p80 type flash. 3. handle m25p80 as well as other slave on multiple chipselects. I just need to know whether the user that requested the transfer is m25p80 driver. If yes, ti-qspi driver can take advantage of memory mapped interface, else just use config port to access SPI bus directly. The problem with this approach is that it's an abomination. It's adding a SPI-user specific hack which is detected by a specific driver. That's really not sane - what happens when we have lots of these kinds of I'm an X SPI-user with drivers detecting that? It's not maintainable in the long term. Yes, your requirements _today_ seem simple and easy, but you're only thinking about today, not tomorrow when you've moved on and someone else has to maintain the mess left behind (or delete it from mainline because they're sick of dealing with a hack.) The spi_message that is received in transfer_one_message() is too generic to imply the slave device that is on the other side of the wire. IMO, the read command does not imply that the slave is m25p80 flash (besides the read opcodes vary across vendors of m25p80 and across modes). I can see both sides of the argument. Mark is saying: if the SPI driver detects that the message to be transmitted is a read command followed by the appropriate number of dummy bytes, and then the data being read _and_ it's using quad-mode access, and the hardware generates _exactly_ that in hardware using the memory mapped mode, there is no reason _not_ to use the hardware to achieve that SPI transaction. The bus activity will be identical to what happens when the SPI controller is used manually to achieve that bus sequence. You're saying: but the documentation says you can't use it for anything except m25p80. If you look at 24.5.4.1.2, it tells you what the SFI generates on the bus, which is: 1. CS active 2. Read command byte sent 3. 1-4 address bytes sent 4. 0-3 dummy bytes sent 5. data bytes read from bus 6. CS inactive So, Mark's point is if we can detect a transaction which fits _that_ bus activity, there's no reason not to use this acceleration for the transaction. What you're failing to counter with is: we don't have enough information in the SPI driver to know how many dummy bytes there are between the address bytes and the data read from the bus. 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 number of bytes */ dummy /= 8; flash-command[0] = nor-read_opcode; m25p_addr2cmd(nor, from, flash-command); t[0].tx_buf = flash-command; t[0].len = m25p_cmdsz(nor) + dummy; spi_message_add_tail(t[0], m); The reason that the number of dummy bytes can't be detected is because it's all hidden in the first transaction as the total number of bytes to be transmitted - and the dummy bytes are uninitialised, so you can't make any assumptions what value they are. There is no way for the SPI driver to know whether these dummy bytes are dummy bytes or whether they have an effect on the targetted device. I think that comprehensively rules out Mark's idea with the SPI core as it stands today: there is no way for the SPI driver to reliably detect a message like a SFI read command by parsing the SPI transmitted message prior to sending it as we can never be sure whether there are dummy bytes to be transmitted. What may make more sense from the SPI point of view is to communicate to all SPI drivers how many dummy bytes are to be transferred. I'm not fully up on SPI, but maybe something like this: t[0].tx_buf = flash-command; t[0].len = m25p_cmdsz(nor); spi_message_add_tail(t[0], m); t[1].tx_buf = dummy_buffer; t[1].len = dummy; t[1].dummy = 1; spi_message_add_tail(t[1], m); This way, we're describing the transfer to the SPI core, and explicitly indicating that there are some dummy bytes. The SPI driver can then tell that these are dummy bytes, and if the SPI message consists of: - transmit 2 to 5 bytes where the first byte is a recognised read command - transmit 0 to 3 dummy bytes - read some bytes then it can make use of the SFI mode to accelerate the operation. This would not be a hack to the SPI code: we're describing to the SPI code what we want to achieve in terms of the activity on the bus, and providing that level of description then allows the SPI driver to make informed decisions on whether
Re: [PATCH 1/8] ARM: dts: AM4372: Reorder the rtc compatible string
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 +0530, Keerthy wrote: Felipe, On Wednesday 05 August 2015 09:01 PM, Felipe Balbi wrote: On Wed, Aug 05, 2015 at 04:19:45PM +0530, Keerthy wrote: Compared to da830-rtc compatibility am3352-rtc is more compatible to the one in am437x. Hence adding the am3352-rtc compatible to cover the entire feature set. The ti,am4372-rtc has no Documentation and not used even in the driver hence removing it. why don't you do the inverse ? Document am4372-rtc and make driver use it ? am3352-rtc suffices for am4372 too. No need to add additional one for am4372. Until we end up needing it, right ? :-) Besides, it's already used in a DTS. What happens if someone branched from that DTS and ships that in a product. RTC will just stop working 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. BTW, this compatible has been in tree since August 2013, IMO it's unfar to drop it just like that. Documenting it would be a better approach. Okay. Can you point me to a file which is already accessing it in dts? Accessing what ? Also, once DTS reaches a major kernel release, it's deemed stable and should be supported. Are we dropping that ? I meant getting used in any other dts files than the one i just dropped it. how can you ever know that for sure ? There are already quite a few third party platforms based on AM437x, how can you be sure those companies don't have their own DTS ? -- balbi signature.asc Description: Digital signature
Re: Linux 4.2.0-rc5: am335x: musb warnings
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_host_rx 1973: Rx interrupt with no errors or packet! musb_ep_program 931: broken !rx_reinit, ep5 csr 0203 musb_host_rx 1973: Rx interrupt with no errors or packet! musb_host_rx 1973: Rx interrupt with no errors or packet! musb_host_rx 1973: Rx interrupt with no errors or packet! musb_host_rx 1973: Rx interrupt with no errors or packet! musb_ep_program 931: broken !rx_reinit, ep5 csr 0003 musb_host_rx 1973: Rx interrupt with no errors or packet! musb_ep_program 931: broken !rx_reinit, ep7 csr 0003 Is this expected behavior? no, that shouldn't happen, but it does and, apparently, in more than one implementation. Wondering if you're running into endpoint limitation due to MUSB's poor transfer scheduling for non-bulk endpoints. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/8] ARM: dts: AM4372: Reorder the rtc compatible string
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 required to be done that way that time, probably author didn't want to be loyal to the king than the king himself ;), see, 1. http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/191206.html 2. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89473.html Regards Afzal -- 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 3/3] serial: 8250: omap: restore registers on shutdown
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, we never send the x_char if the TX-DMA never fails to do its job. The comment above uart_send_xchar() says it is high priority. What do you suggest, wait until the transfer completes, send the x_char _or_ pause the transfer send that byte and then send the byte? In both cases we have to wait until for the FIFO-empty interrupt to make sure we don't overrun that TX-FIFO. I *think* waiting until the transfer completes would be simpler but it is not necessarily high priority. Regards, Peter Hurley Sebastian -- 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 6/7] ARM: dts: omap3-devkit8000: add LCD panels
* Anthoine Bourgeois anthoine.bourge...@gmail.com [150805 14:53]: On Wed, Aug 05, 2015 at 04:08:12AM -0700, Tony Lindgren wrote: * Anthoine Bourgeois anthoine.bourge...@gmail.com [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.3/dt thanks. However, the last two patches won't apply for me, care to repost against what I have in omap-for-v4.3/dt? Ok, it's done. I forgot to sign my patches the first time, the last two patches are sign in v2. I'll be careful next time, sorry. And I did not notice that yet either.. I'll take that as permission to add your Signed-off-by to the missing ones too. I'll just do a new omap-for-v4.3/dt-v2 branch as I did not yet add them into Linux next. 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: [PATCH] usb: musb: omap2430: use *syscon* framework API to write to mailbox register
* Kishon Vijay Abraham I kis...@ti.com [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 great. https://lkml.org/lkml/2015/6/24/231 Maybe I should have explained this in the previous thread. The *otghs* register that we are trying to access here does _not_ belong to the PHY. It acts as mailbox register from MUSB glue (TI integration layer) to MUSB core. That's why it's programmed in the TI glue layer (omap2430.c). Even when we were using the older API [omap_control_usb_set_mode()], we first call omap_musb_mailbox from the PHY drivers (phy-twl4030-usb.c, phy-twl6030-usb.c) and then omap_musb_mailbox in the TI glue writes to the control module instead of PHY drivers directly calling omap_control_usb_set_mode(). Hmm looking at Table 18-204. CONTROL_USBOTGHS_CONTROL it seems to mention transceiver for quite a few bitfields :) Probably what that register does is control a PHY over ULPI. So from Linux kernel point of view we're best off treating it as a PHY. It seems it should have a minimal PHY driver similar to what we have for dm816x control module in drivers/phy/phy-dm816x-usb.c. For reference, here is the register bitfields pasted from 4460 TRM: Table 18-204. CONTROL_USBOTGHS_CONTROL, p3972 Physical Address 0x4A00 233C BIT NAMEDESCIPTION 8 DISCHRGVBUS ... OTG transceiver does (not) discharge VBUS ... 7 CHRGVBUS... OTG transceiver does (not) charge VBUS ... 6 IDPULLUP... OTG transceiver does (not) drive VBUS ... 4 IDDIG ... OTG transceiver does (not) apply a pullup to ID ... 3 SESSEND ... VBUS voltage is above/below VB_SESS_END ... 2 VBUSVALID ... VBUS is above the threshold ... 1 BVALID ... VBUS voltage is above/below VB_SESS_VLD ... 0 AVALID ... BUS voltage is above/below VA_SESS_VLD ... So how about just adding ONTROL_USBOTGHS_CONTROL support to the existing drivers/phy/phy-omap-usb2.c instead? It seems that it should allow us to completely get rid of the custom mailbox stuff for MUSB 2430 support? So let's sort that issue first. It also seems this just completely breaks the MUSB support? Why do you think so? If *syscon-otghs* is not present in dt, then it'll fall-back to using the *ctrl-module* and everything should work seamlessly. OK that's good to hear. IMO drivers/phy/phy-omap4.c or similar should manage the syscon-otghs syscon register, not MUSB driver. 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: [PATCH v2 1/2] ARM: dts: omap3-devkit8000: add LCD panels
* Anthoine Bourgeois anthoine.bourge...@gmail.com [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: 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: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
On Wed, Aug 05, 2015 at 02:56:09PM +0200, Michal Suchanek wrote: On 5 August 2015 at 14:44, Mark Brown broo...@kernel.org 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 detection that we are talking to a SPI flash memory. Why care - if something is physically in the same format as a flash read command how would a device be able to tell that it wasn't actually a flash read command? The signals sent on the bus are going to be identical anyway. Not only must the command be the same but also the response must be tha same. What difference would that make? The caller is sending a single SPI operation and this is a user visible thing... The flash chip responds by sending arbitrary amount of data. Given that transfer_one gets only the part that sends the read command and the part to do the actual read may or may not follow this is getting a bit hairy. Add in dummy bytes due to fast-read lag and page write wrap-around and you get something that you definitely do not want unless you are really sure that there is a flash memory on the other end of the wire. So if you're doing this you may have a good reason to implement transfer_one_message() instead. Or perhaps implement it in the core and provide operations to do the map and unmap. And of course if this sort of requirement exists that's an obvious thing that must be documented in the interfaces but isn't. We need a lot more thought about the interface here, the lack of any explanation of what the interface is supposed to be and the fact that all questions about it are being answered in terms of describing the specific system are both a bit worrying. signature.asc Description: Digital signature
Re: [PATCH 00/11] omap_hsmmc: voltage switching and tuning
* Kishon Vijay Abraham I kis...@ti.com [150805 08:03]: Hi, On Wednesday 05 August 2015 04:13 PM, Tony Lindgren wrote: * Kishon Vijay Abraham I kis...@ti.com [150730 00:49]: Patch series implements voltage switching and tuning for omap_hsmmc driver. Did basic read/write test in J6, J6 Eco, Beagle-x15, AM437x EVM, Beaglebone black, OMAP5 uEVM and OMAP4 PANDA. Your tests are missing omap3? I don't have one at my disposal :-( I'll try to find one and add omap3 tests. Great :) Beagle xm is a good one to test the USB PHY stuff on and also MMC. Having USB cable connected or EHCI loaded blocks the PM though, so NFSroot is not very usable for testing on it. If you want to test PM over NFSroot, boards with the smsc911x known to work with PM are at least omap3-evm-37xx.dts and logicpd-torpedo-37xx-devkit.dts. Since you tinker with the USB PHYs, torpedo has MUSB working the same way as the beagle boards, EVM I think can be modified that way but by default has diffent PHY. Also overo tobi boards work with PM but only for retntion idle and not off idle, and map3-sbc-t3517.dts probably can be made to work with PM but I have mine as a gateway and have not been able to test with it. Probably also zoom3 boards with later processor boards can be made to work, the LDP has early omap34xx variants and can't be made to work reliably. I don't have omap3-lilly, but I'd assume that can also be made to work with PM if not already working. I suggest you add some omap3 tests in general as otherwise you are only testing a subset of the driver features and completely missing things like rutnime PM and save and restore for the deeper idle states. yeah, I'll do those tests and re-post the series. Thanks! 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: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
On Thu, Aug 06, 2015 at 01:42:32PM +0200, Michal Suchanek wrote: On 6 August 2015 at 13:23, Mark Brown broo...@kernel.org 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 bother with the flag, we can just pattern match on the format of the message. If that doesn't work then probably this isn't a great interface and a separate, application specific interface makes more sense. The messages are sensible interface for communicating with a device that interprets a particular part of the mesasge as address and another particular part of the message as command and sends same amount of junk before reply as the flash chip would. If your device That's just a statement that it's possible to do things this way, it's not clear to me that it's an explanation as to why it is sensible to do so - the obvious thing to do there would be to specify the flash operation as a flash operation rather than reverse engineer the flash operation from the wire format. happens to send reply immediately part of it is trashed. If it happens to interpret address differently the data ends up in random part of your memory. So no, that is not something you can autodetect. If this stuff doesn't appear in the spi_message in some observable form then I'd expect that any existing flash support is broken since a SPI controller that doesn't have any acceleration is just going to do what the message says. At the end of the day you have valid SPI messages but the m25p80 layer adds interpretation to those messages which may not always give correct result. Which comes back to the thing I keep saying about needing some sort of information about what the flag means and the questions about why this is a good interface... On the other hand, if you ever get to m25p80 or spi-nor you can assume any message you send goes to a flash chip and insist that the controller uses the flash-specific interface. There's an awful lot of flashes out there connected to controllers that don't implement any sort of acceleration for flash, I'm not convinced that your assumption there is valid. If there is possibility of connecting different kind of devices to multiple chipselects on the same master then you probably want to select this option per message or per slave. We definitely need to account for that. signature.asc Description: Digital signature
Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
On Thu, Aug 6, 2015 at 3:51 PM, Russell King - ARM Linux
li...@arm.linux.org.uk 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 driver, I dont want to
break it). Or pump any spi_message on to SPI bus directly.
2. take advantage of memory mapped port in order to increase read
throughput( and use dma in future) when the slave is a m25p80 type flash.
3. handle m25p80 as well as other slave on multiple chipselects.
I just need to know whether the user that requested the transfer is
m25p80 driver. If yes, ti-qspi driver can take advantage of memory
mapped interface, else just use config port to access SPI bus directly.
The problem with this approach is that it's an abomination. It's adding
a SPI-user specific hack which is detected by a specific driver. That's
really not sane - what happens when we have lots of these kinds of I'm
an X SPI-user with drivers detecting that? It's not maintainable in the
long term.
Yes, your requirements _today_ seem simple and easy, but you're only
thinking about today, not tomorrow when you've moved on and someone else
has to maintain the mess left behind (or delete it from mainline because
they're sick of dealing with a hack.)
The spi_message that is received in transfer_one_message() is too
generic to imply the slave device that is on the other side of the wire.
IMO, the read command does not imply that the slave is m25p80 flash
(besides the read opcodes vary across vendors of m25p80 and across modes).
I can see both sides of the argument.
Mark is saying: if the SPI driver detects that the message to be transmitted
is a read command followed by the appropriate number of dummy bytes, and
then the data being read _and_ it's using quad-mode access, and the hardware
generates _exactly_ that in hardware using the memory mapped mode, there is
no reason _not_ to use the hardware to achieve that SPI transaction. The
bus activity will be identical to what happens when the SPI controller is
used manually to achieve that bus sequence.
You're saying: but the documentation says you can't use it for anything
except m25p80. If you look at 24.5.4.1.2, it tells you what the SFI
generates on the bus, which is:
1. CS active
2. Read command byte sent
3. 1-4 address bytes sent
4. 0-3 dummy bytes sent
5. data bytes read from bus
6. CS inactive
So, Mark's point is if we can detect a transaction which fits _that_
bus activity, there's no reason not to use this acceleration for the
transaction.
What you're failing to counter with is: we don't have enough information
in the SPI driver to know how many dummy bytes there are between the
address bytes and the data read from the bus.
Irrespective of the dummy bytes.
What if the spi device is not a FLASH ROM, but some other device,
which receives a data packet that accidentally looks like an m25p80 READ
command?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 v5 0/3] dra7xx: Add PM support to PCIe
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 incomplete patch. Changes from v3: *) Fix compilation errors when individual patches are applied Changes from v2: *) Used SET_SYSTEM_SLEEP_PM_OPS and SET_NOIRQ_SYSTEM_SLEEP_PM_OPS for populating PM ops. Changes from v1: *) Moved resetting and setting of MSE bit to pci-dra7xx. The comment to reset and set ISE is not done now since I don't have a card with IO space. Once I get to test that, I'll post a separate patch for handling that. Kishon Vijay Abraham I (3): PCI: host: pci-dra7xx: Disable pm_runtime on get_sync failure PCI: host: pci-dra7xx: add pm support to pci dra7xx PCI: host: pci-dra7xx: Idle the module by disabling MSE bit Hi Kishon, Looks good! :-) Reviewed-by: Jingoo Han jingooh...@gmail.com Best regards, Jingoo Han drivers/pci/host/pci-dra7xx.c | 95 - 1 file changed, 94 insertions(+), 1 deletion(-) -- 1.7.9.5 -- 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
[PATCH] ARM: OMAP5 / DRA7: Introduce workaround for 801819
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:
1) Do not use the write-back no-allocate memory type.
2) Do not issue write-back cacheable stores at any time when the cache
is disabled (SCTLR.C=0) and the MMU is enabled (SCTLR.M=1). Because it
is implementation defined whether cacheable stores update the cache when
the cache is disabled it is not expected that any portable code will
execute cacheable stores when the cache is disabled.
For implementations of Cortex-A15 configured without the “L2 arbitration
register slice” option (typically one or two core systems), you must
also do the following:
3) Disable write-streaming in each CPU by setting ACTLR[28:25] = 0b
So, we provide an option to disable write streaming on OMAP5 and DRA7.
It is a rare condition to occur and may be enabled selectively based
on platform acceptance of risk.
Applies to: A15 revisions r2p0, r2p1, r2p2, r2p3 or r2p4 and REVIDR[3]
is set to 0.
Based on ARM errata Document revision 18.0 (22 Nov 2013)
Note: the configuration for the workaround needs to be done with
each CPU bringup, since CPU0 bringup is done by bootloader, it is
recommended to have the workaround in the bootloader, kernel also does
ensure that CPU0 has the workaround and makes the workaround active
when CPU1 gets active.
With CONFIG_SMP disabled, it is expected to be done by the bootloader.
This does show significant degradation in synthetic tests such as
mbw (https://packages.qa.debian.org/m/mbw.html)
mbw -n 100 100|grep AVG (on a test platform)
Without enabling the erratum:
AVG Method: MEMCPY Elapsed: 0.13406 MiB: 100.0 Copy: 745.913 MiB/s
AVG Method: DUMBElapsed: 0.06746 MiB: 100.0 Copy: 1482.357 MiB/s
AVG Method: MCBLOCK Elapsed: 0.03058 MiB: 100.0 Copy: 3270.569 MiB/s
After enabling the erratum:
AVG Method: MEMCPY Elapsed: 0.13757 MiB: 100.0 Copy: 726.913 MiB/s
AVG Method: DUMBElapsed: 0.12024 MiB: 100.0 Copy: 831.668 MiB/s
AVG Method: MCBLOCK Elapsed: 0.09243 MiB: 100.0 Copy: 1081.942 MiB/s
Most benchmarks are designed for specific performance analysis, so
overall usecase must be considered before making a decision to
enable/disable the erratum workaround.
Pending internal investigation, the erratum is kept disabled by default.
Cc: Russell King rmk+ker...@arm.linux.org.uk
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Tony Lindgren t...@atomide.com
Suggested-by: Richard Woodruff r-woodru...@ti.com
Suggested-by: Brad Griffis bgrif...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Since this is a generic ARM erratum with potentially other SoCs
benefitting from a workaround.. the only problem with a generic
workaround, as far as I can see if the SoC specific smc based acr
modification. It will be great to get some direction in this front.
Also note:
We did notice that this erratum was discussed earlier [1] however,
with internal evaluation, it was summarized that this does impact our
SoCs.
[1] https://lists.linaro.org/pipermail/linaro-kernel/2013-June/004687.html
arch/arm/mach-omap2/Kconfig | 8 +++
arch/arm/mach-omap2/omap-secure.h | 1 +
arch/arm/mach-omap2/omap-smp.c| 48 +++
3 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4a023e8d1bdb..b62835562ff0 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -245,4 +245,12 @@ endmenu
endif
+config OMAP5_ERRATA_801819
+ bool Errata 801819: An eviction from L1 data cache might stall
indefinitely
+ depends on SOC_OMAP5 || SOC_DRA7XX
+ help
+ 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.
+
endmenu
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index af2851fbcdf0..bae263fba640 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -46,6 +46,7 @@
#define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX0x109
#define OMAP5_MON_AMBA_IF_INDEX0x108
+#define OMAP5_DRA7_MON_SET_ACR_INDEX 0x107
/* Secure PPA(Primary Protected Application) APIs */
#define OMAP4_PPA_L2_POR_INDEX 0x23
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 5305ec7341ec..faaf366c220e 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -50,6 +50,39 @@ void __iomem *omap4_get_scu_base(void)
return scu_base;
}
+#ifdef CONFIG_OMAP5_ERRATA_801819
+void omap5_erratum_workaround_801819(void)
+{
+ u32 acr, revidr;
+ u32 acr_mask;
+
+ /* REVIDR[3]
