Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
Hi Mark, On 13/11/14 00:23, Mark Brown wrote: On Wed, Nov 12, 2014 at 04:40:51PM +0200, Jyri Sarha wrote: It would make the most sense to get these in trough fbdev tree. So it would be nice to get acked-bys (if the patches are Ok) for ASoC side changes from appropriate maintainers. So, this is a very large series which gets reposted every so often to no apparent interest from the video side, there's been no response at all Sorry for the lack of communication. We've been discussing this series on irc. It's been mostly about how to manage the device/driver split between drivers/video/ and sound/ sides. that I can remember and even the earlier bits of the series before it starts touching audio don't seem to be getting merged. What's going on here? The series is all audio in terms of functionality. The first few patches could probably be merged independently, but I've wanted this whole OMAP HDMI audio rewrite to be in one series. I'll start testing this latest series, and I hope we can merge it for the next merge window so that we'll finally get the OMAP HDMI audio working. I don't have much knowledge of the asoc architecture, so I probably can't comment much on the sound/ side design. For me the most important things are that 1) it works 2) I can easily unload/load the modules (which was broken in some of the earlier versions). As a more general discussion item, I'm still wondering why it feels like we (OMAP) are doing something totally new here. I'd imagine that almost every device with HDMI would need both video and audio side support, and those sides need to work together. And the audio side would need to get notified of things like cable disconnect (i.e. the video stream is stopped - audio must be stopped also). But if I've understood right, there was no similar existing code to be found. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCHv6 5/5] hwspinlock/omap: add support for dt nodes
Hi Suman, On Wed, Nov 12, 2014 at 9:50 PM, Suman Anna s-a...@ti.com wrote: None of the OMAPs have multiple IP instances, and as such the base-id is an optional property. I have made this change to make sure we atleast attempt to use the value if mentioned in DT and not hard-coding the value to begin with (going by the optional property semantics). If and when multiple instances get added and a secondary node doesn't add the property, the node will not be registered with the core due to an overlap failure. Ok, that sounds good. Thanks, Ohad. -- 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: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Thu, 13 Nov 2014 10:05:28 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: [snip] I don't have much knowledge of the asoc architecture, so I probably can't comment much on the sound/ side design. For me the most important things are that 1) it works 2) I can easily unload/load the modules (which was broken in some of the earlier versions). As a more general discussion item, I'm still wondering why it feels like we (OMAP) are doing something totally new here. I'd imagine that almost every device with HDMI would need both video and audio side support, and those sides need to work together. And the audio side would need to get notified of things like cable disconnect (i.e. the video stream is stopped - audio must be stopped also). But if I've understood right, there was no similar existing code to be found. I recently posted a patch on the HDMI CODEC to interface a HDMI transmitter http://mailman.alsa-project.org/pipermail/alsa-devel/2014-October/082745.html and I saw only a few dependencies between the 2 subsystems: - the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -), - the CODEC must alert the transmitter on audio start and stop. I don't think that stopping audio streaming on HDMI disconnection is useful. I even let audio streaming start when the HDMI cable is disconnected. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
Hi, On 13/11/14 11:17, Jean-Francois Moine wrote: On Thu, 13 Nov 2014 10:05:28 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: [snip] I don't have much knowledge of the asoc architecture, so I probably can't comment much on the sound/ side design. For me the most important things are that 1) it works 2) I can easily unload/load the modules (which was broken in some of the earlier versions). As a more general discussion item, I'm still wondering why it feels like we (OMAP) are doing something totally new here. I'd imagine that almost every device with HDMI would need both video and audio side support, and those sides need to work together. And the audio side would need to get notified of things like cable disconnect (i.e. the video stream is stopped - audio must be stopped also). But if I've understood right, there was no similar existing code to be found. I recently posted a patch on the HDMI CODEC to interface a HDMI transmitter http://mailman.alsa-project.org/pipermail/alsa-devel/2014-October/082745.html Jyri or Peter knows this better, but I think one difference with OMAP HDMI case and tda998x is that tda998x is an external encoder, and you transfer audio data to it via i2s or spdif, whereas OMAP HDMI is inside the SoC, and the HDMI IP gets the audio data via system DMA. The system DMA transfers are triggered by the HDMI IP, and the HDMI IP has to be enabled and properly configured for the DMA ports to function. So, correct me if I'm wrong, but I think this is the fundamental difference: In your case, the actual audio playback happens with the i2s or spdif side. You can enable the playback at any time, no matter what is the status of tda998x. If tda998x is not operational, the audio data will just go to /dev/null. In our case, the actual audio playback happens inside the HDMI block. We need the whole HDMI block to be operational and correctly configured for (fake or real) playback to be possible. and I saw only a few dependencies between the 2 subsystems: - the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -), The video mode (i.e. availability of audio) or the EDID (i.e. the supported audio parameters) may change at any time, so I presume in your series the video side will inform the codec of these changes at any point? - the CODEC must alert the transmitter on audio start and stop. I don't think that stopping audio streaming on HDMI disconnection is And you allow audio playback also if the monitor does not support audio, or the video mode does not supprot audio? useful. I even let audio streaming start when the HDMI cable is disconnected. Ah, this is actually unclear thing to me: what should the audio side behavior be when the HDMI cable is disconnected or the video is blanked? I believe the options are: a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere? b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave? c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work. Jyri, were there some other options we discussed? Currently, the OMAP HDMI version does c). It's the easiest solution for us. Option a) is a bit problematic for us, as it requires the HDMI IP side to be fully operational, with the video output configured and enabled, as that is what drives the audio DMA. If we stop the video, I believe the audio DMA will freeze, and it'll lead to timeouts on the audio side. I haven't tried, but I believe we could program the HDMI IP to some safe default video mode if the cable is disconnected, and turn off the actual HDMI PHY, so that the audio side could work even if the HDMI stream is not going anywhere. I think it would be quite big change to how the HDMI driver works at the moment. But then, if the cable _is_ connected and the video mode is such that it cannot not support audio, I wonder if we can still fake the audio playback or will the HDMI IP get confused... Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
Tony,
On Thu, 6 Nov 2014, Tony Lindgren wrote:
Any comments on the patch below? Let me know if you want to keep the
devm stuff out of kernel/irq/manage.c.
Sorry, this slipped through the cracks.
+static int setup_wakeirq(struct device *dev, unsigned int wakeirq,
+unsigned long wakeflags, bool devm)
+{
+ int ret;
+
+ if (!(dev wakeirq)) {
+ pr_err(Missing device or wakeirq for %s irq %d\n,
+ dev_name(dev), wakeirq);
+ return -EINVAL;
+ }
+
+ if (!(wakeflags
+ (IRQF_TRIGGER_LOW | IRQF_TRIGGER_HIGH | IRQF_ONESHOT))) {
+ pr_err(Invalid wakeirq for %s irq %d, must be level oneshot\n,
+ dev_name(dev), wakeirq);
This looks odd.
Why do you want to enforce LEVEL and ONESHOT? I can see the point for
ONESHOT, but I'm wondering about the requirement for level.
Now if you really want to enforce level AND oneshot, your check is
wrong as it will not trigger on
wakeflags = IRQF_TRIGGER_LOW;
wakeflags = IRQF_TRIGGER_HIGH;
wakeflags = IRQF_ONESHOT;
Not what you really want, right?
+int request_wake_irq(struct device *dev, unsigned int wakeirq,
+unsigned long wakeflags)
+{
+ return setup_wakeirq(dev, wakeirq, wakeflags, false);
+}
+EXPORT_SYMBOL(request_wake_irq);
_GPL please
+
+int devm_request_wake_irq(struct device *dev, unsigned int wakeirq,
+ unsigned long wakeflags)
+{
+ return setup_wakeirq(dev, wakeirq, wakeflags, false);
Shouldnt that have devm = true?
Thanks,
tglx
--
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: [PATCHv6 4/5] hwspinlock/core: add common OF helpers
Hi Suman,
On Wed, Nov 12, 2014 at 9:32 PM, Suman Anna s-a...@ti.com wrote:
Is this the validation you mentioned which requires the existence of
hwspinlock/core: maintain a list of registered hwspinlock banks ?
Well, not exactly. The validation is on the following segment,
+ id = of_hwspin_lock_simple_xlate(bank, args);
+ if (id 0 || id = bank-num_locks) {
+ ret = -EINVAL;
+ goto out;
+ }
I'm not entirely convinced that this justifies adding the proposed
linked list. Can't we can get the base_id and number of locks by
traversing the DT?
That said, it is also needed to provide the support for deferred probing
without changing the return code conventions on the existing API.
Here too, adding a data structure maintaining memory objects and
taking care of it life cycle seems a bit overkill for anything to do
with return values.
Yes, and wouldn't that require that the id is validated? It just cannot
return any return value, and expect it will be verified somewhere else
or in a following API call. Not doing the validation unnecessarily
complicates the system usage of a lock as you are sharing an invalid
lock to a remote processor and then you have two validation failure
paths on different processors.
Validation is great but I'm still not convinced it can't be done
without maintaining another data structure.
Please show me specific technical issues that can't be resolved
without adding the proposed linked list.
Thanks,
Ohad.
--
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 v3 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On Tue, 11 Nov 2014, R, Vignesh wrote: On Tue, 11 Nov 2014, Vignesh R wrote: In one shot mode, sequencer automatically disables all enabled steps at the end of each cycle. (both ADC steps and TSC steps) Hence these steps need not be saved in reg_se_cache for clearing these steps at a later stage. Also, when ADC wakes up Sequencer should not be busy executing any of the config steps except for the charge step. Previously charge step was 1 ADC clock cycle and hence it was ignored. Signed-off-by: Vignesh R vigne...@ti.com --- [...] - tsadc-reg_se_cache |= val; You didn't answer my question about this? I did reply to the question in the previous thread. Previously, TSC did not reliably re-enable its steps as the TSC irq handler received false pen up events. Hence, in order to use TSC after ADC operation, it was necessary to save and re-enable TSC steps (basically, to keep TSC steps enabled always). The change was more of a workaround to overcome limitation of TSC irq handler. With this series of patches, TSC irq handler is very reliable and the workaround is no longer required. Okay, thanks for the explanation. By the way, your mailer doesn't appear to quote previous messages. Is there any way to fix that? am335x_tscadc_need_adc(tsadc); tscadc_writel(tsadc, REG_SE, val); diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h index c99be5dc0f5c..fcce182e4a35 100644 --- a/include/linux/mfd/ti_am335x_tscadc.h +++ b/include/linux/mfd/ti_am335x_tscadc.h @@ -128,6 +128,7 @@ /* Sequencer Status */ #define SEQ_STATUS BIT(5) +#define CHARGE_STEP0x11 #define ADC_CLK300 #define TOTAL_STEPS16 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v4 2/8] net: can: c_can: Introduce c_can_driver_data structure
On 11/07/2014 03:49 PM, Roger Quadros wrote:
We want to have more data than just can_dev_id to be present
in the driver data e.g. TI platforms need RAMINIT register
description. Introduce the c_can_driver_data structure and move
the can_dev_id into it.
Tidy up the way it is used on probe().
Signed-off-by: Roger Quadros rog...@ti.com
[...]
@@ -198,21 +206,19 @@ static int c_can_plat_probe(struct platform_device
*pdev)
struct net_device *dev;
struct c_can_priv *priv;
const struct of_device_id *match;
- const struct platform_device_id *id;
struct resource *mem, *res;
int irq;
struct clk *clk;
-
- if (pdev-dev.of_node) {
- match = of_match_device(c_can_of_table, pdev-dev);
- if (!match) {
- dev_err(pdev-dev, Failed to find matching dt id\n);
- ret = -EINVAL;
- goto exit;
- }
- id = match-data;
+ const struct c_can_driver_data *drvdata;
+
+ match = of_match_device(c_can_of_table, pdev-dev);
+ if (match) {
+ drvdata = match-data;
+ } else if (pdev-id_entry-driver_data) {
+ drvdata = (struct c_can_driver_data *)
+pdev-id_entry-driver_data;
^^
I've changes this to platform_get_device_id() while aplying.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 3/8] net: can: c_can: Add RAMINIT register information to driver data
On 11/07/2014 03:49 PM, Roger Quadros wrote:
Some platforms (e.g. TI) need special RAMINIT register handling.
Provide a way to store RAMINIT register description in driver data.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/net/can/c_can/c_can.h | 6 ++
drivers/net/can/c_can/c_can_platform.c | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 26c975d..3c305a1 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -171,6 +171,12 @@ enum c_can_dev_id {
struct c_can_driver_data {
enum c_can_dev_id id;
+
+ /* RAMINIT register description. Optional. */
+ u8 num_can; /* Number of CAN instances on the SoC */
+ u8 *raminit_start_bits; /* Array of START bit positions */
+ u8 *raminit_done_bits; /* Array of DONE bit positions */
+ bool raminit_pulse; /* If set, sets and clears START bit (pulse) */
};
/* c_can private data structure */
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index 1546c2b..20deb67 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -250,6 +250,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
}
priv = netdev_priv(dev);
+
Dropped this hunk while applying.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 4/8] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 11/07/2014 03:49 PM, Roger Quadros wrote: Some TI SoCs like DRA7 have a RAMINIT register specification different from the other AMxx SoCs and as expected by the existing driver. To add more insanity, this register is shared with other IPs like DSS, PCIe and PWM. Provides a more generic mechanism to specify the RAMINIT register location and START/DONE bit position and use the syscon/regmap framework to access the register. What about the existing device trees that don't have the syscon-raminit phandle? We can either keep the existing init routines or create regmap in the platform driver an use the new ones. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH] mtd: nand: omap: Fix NAND enumeration on 3430 LDP
On 11/12/2014 08:02 PM, Tony Lindgren wrote: * pekon pe...@pek-sem.com [141109 11:31]: On Saturday 08 November 2014 04:18 AM, Tony Lindgren wrote: Right. I doubt anybody has bch8 rootfs on LDP.. And considering u-boot must be ham1 to boot at all, that's what we should change for the devices that do not have not standardized on bch8. My view on this is slightly different: - Lately, everyone seems to have migrated to BCH8. - Also HAM1 does not have strength to fix bitflips in aging NAND. So if someone already has OMAP3-LDP deployed on field then its NAND would have already aged to such an extend that HAM1 may not be sufficient. OK so it makes sense to keep it as BCH8 then. Would be nice to get the writing u-boot from kernel issue fixed somehow though as people are hitting that for sure. What about performance impact? OMAP3 doesn't have ELM module. So error location for BCH8 has to be done in software. My question is.. Moving back to HAM1 should be decided based on statistics rather than rule of breaking backward compatibility. So please review: (1) How many user of OMAP3-Zoom or other old boards complaining about using BCH8 in mainline kernel? OR 0 (2) How many users of OMAP3 legacy boards are migrating to newer kernel? Quite a few for sure, but are probably also using rootfs on MMC instead. At-least I have not, rather most of the OMAP3 users I interacted via TI's E2E forum wanted to migrate to BCH8 or even BCH16, as HAM1 was not sufficient for their usage. So whatever you decide on this topic, please be cautious that you don't re-invent work for yourself, as I did. It took me lot of time and testing effort on multiple boards to migrate HAM1 to BCH8, And add BCH16 for newer devices. Right no objections to using BCH8 for rootfs, except it stopped working over past year or so. This would be BCH8-sw on OMAP3 right? AM3xx uses BCH8-hw and that seems to work fine. So it seems nobody has used/tested BCH8-sw. And it seems the settings should be partition specific because of u-boot requiring HAM1. I don't think we have partition specific ECC scheme support in u-boot or kernel, so it will become messy to manage. That means we either stick with HAM1 for all partitions or don't support NAND boot at all and go with any other ECC scheme for OMAP3. cheers, -roger -- 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 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
On 12/11/14 17:02, Tony Lindgren wrote: And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple places in the kernel. I wonder if adding a pinmux entry for it could cause some rather odd problems. They can all use pinctrl-single no problem. Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux, and we have code in mach-omap2 that also touch DEVCONF1, without any knowledge (and locking) between those... So _maybe_ that's not an issue, as the pinmux config we have here is fixed, and done once at boot time, and maybe the code in mach-omap2 that touch DEVCONF1 is also ran just once and not at the same time as the pinmux. But I don't know if that's so. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 1/5] video: omapdss: Add opa362 driver
On 13/11/14 00:10, Marek Belisko wrote:
opa362 is amplifier for video and can be connected to the tvout pads
of the OMAP3. It has one gpio control for enable/disable of the output
(high impedance).
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
drivers/video/fbdev/omap2/displays-new/Kconfig | 6 +
drivers/video/fbdev/omap2/displays-new/Makefile| 1 +
.../fbdev/omap2/displays-new/amplifier-opa362.c| 343
+
I think it would be better to rename this to encoder-opa362.c. It's not
encoder as such, but it falls into the same category.
include/video/omap-panel-data.h| 12 +
4 files changed, 362 insertions(+)
create mode 100644 drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
diff --git a/drivers/video/fbdev/omap2/displays-new/Kconfig
b/drivers/video/fbdev/omap2/displays-new/Kconfig
index e6cfc38..211b3ec 100644
--- a/drivers/video/fbdev/omap2/displays-new/Kconfig
+++ b/drivers/video/fbdev/omap2/displays-new/Kconfig
@@ -1,6 +1,12 @@
menu OMAP Display Device Drivers (new device model)
depends on OMAP2_DSS
+config DISPLAY_AMPLIFIER_OPA362
Here also use ENCODER instead.
+tristate external analog amplifier with output disable/high-Z (e.g.
OPA362)
+ help
+ Driver to enable an external analog TV amplifier (e.g. OPA362)
+ through a GPIO.
The indentation above seems funny.
The text looks a bit odd. So is this a driver for OPA362, or is this a
generic driver for any similar devices? Most of the names and code makes
me think this is a driver for OPA362, but the text above quite clearly
gives the impression that this is a driver for any analog video amp,
with single enable gpio.
+
config DISPLAY_ENCODER_TFP410
tristate TFP410 DPI to DVI Encoder
help
diff --git a/drivers/video/fbdev/omap2/displays-new/Makefile
b/drivers/video/fbdev/omap2/displays-new/Makefile
index 0323a8a..b311542 100644
--- a/drivers/video/fbdev/omap2/displays-new/Makefile
+++ b/drivers/video/fbdev/omap2/displays-new/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_DISPLAY_AMPLIFIER_OPA362) += amplifier-opa362.o
obj-$(CONFIG_DISPLAY_ENCODER_TFP410) += encoder-tfp410.o
obj-$(CONFIG_DISPLAY_ENCODER_TPD12S015) += encoder-tpd12s015.o
obj-$(CONFIG_DISPLAY_CONNECTOR_DVI) += connector-dvi.o
diff --git a/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
b/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
new file mode 100644
index 000..8065a28
--- /dev/null
+++ b/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
@@ -0,0 +1,343 @@
+/*
+ * OPA362 analog video amplifier with output/power control
+ *
+ * Copyright (C) 2014 Golden Delicious Computers
+ * Author: H. Nikolaus Schaller h...@goldelico.com
+ *
+ * based on encoder-tfp410
+ *
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Tomi Valkeinen tomi.valkei...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ */
+
+#include linux/gpio.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of_gpio.h
+
+#include video/omapdss.h
+#include video/omap-panel-data.h
+
+struct panel_drv_data {
+ struct omap_dss_device dssdev;
+ struct omap_dss_device *in;
+
+ int enable_gpio;
+
+ struct omap_video_timings timings;
+};
+
+#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
+
+static int opa362_connect(struct omap_dss_device *dssdev,
+ struct omap_dss_device *dst)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata-in;
+ int r;
+
+ dev_dbg(dssdev-dev, connect\n);
+
+ if (omapdss_device_is_connected(dssdev))
+ return -EBUSY;
+
+ r = in-ops.atv-connect(in, dssdev);
+ if (r)
+ return r;
+
+ dst-src = dssdev;
+ dssdev-dst = dst;
+
+ return 0;
+}
+
+static void opa362_disconnect(struct omap_dss_device *dssdev,
+ struct omap_dss_device *dst)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata-in;
+
+ dev_dbg(dssdev-dev, disconnect\n);
+
+ WARN_ON(!omapdss_device_is_connected(dssdev));
+ if (!omapdss_device_is_connected(dssdev))
+ return;
+
+ WARN_ON(dst != dssdev-dst);
+ if (dst != dssdev-dst)
+ return;
+
+ dst-src = NULL;
+ dssdev-dst = NULL;
+
+ in-ops.atv-disconnect(in, ddata-dssdev);
+}
+
+static int opa362_enable(struct omap_dss_device *dssdev)
+{
+ struct panel_drv_data *ddata = to_panel_data(dssdev);
+ struct omap_dss_device *in = ddata-in;
+ int r;
+
+ dev_dbg(dssdev-dev, enable\n);
+
+ if (!omapdss_device_is_connected(dssdev))
+
Re: [PATCH] mtd: nand: omap: Fix NAND enumeration on 3430 LDP
On 11/09/2014 09:29 PM, pekon wrote: On Saturday 08 November 2014 04:18 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [141107 01:59]: On 11/07/2014 11:35 AM, Roger Quadros wrote: On 11/06/2014 08:03 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [141105 03:02]: In commit 7d5929c1f343 (mtd: nand: omap: Revert to using software ECC by default), we switched back to using 1-bit SW ECC scheme by default. However commit b491da7233d5 (mtd: nand: omap: clean-up ecc layout for BCH ecc schemes) didn't take into account the 1-bit SW scheme (i.e. OMAP_ECC_HAM1_CODE_SW) when checking for small page devices because it was already got rid of one commit earlier. Consider OMAP_ECC_HAM1_CODE_SW while deciding if we can proceed with small page devices or not. Fixes: 7d5929c1f34 (mtd: nand: omap: Revert to using software ECC by default) Cc: sta...@vger.kernel.org[3.17+] Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Roger Quadros rog...@ti.com --- [...] Well I'm wrong about the OMAP3 information. OMAP3 does support BCH4 and BCH8 as well. I'm don't thinkg small page check is right. For BCH8 we need 13 bytes per 512 bytes. In the LDP case we have page size:1024 and OOB size: 32. Thus for BCH8 we need 26 bytes per page. which should fit in 32 bytes OOB. So this check is bogus in that case. Pekon, can you please explain why you check for 64 bytes OOB size for all ECC schemes? Accept this is a bug. As I re-review now, small-page check is applicable only for BCH ECC schemes, and not for HAM1. But 32 bytes OOB can accomodate BCH8 codes. right? Tony, The question for backward compatibility still remains. Even if OMAP3 supports bch8 do we stick to the scheme that was used in legacy boot or do we switch? Well for the boards that had a standard file system, we should support that. But at least for the LDP, there was only the bootable microSD card AFAIK: http://support.logicpd.com/ProductDownloads/LegacyProducts/ZoomOMAP34xMDK.aspx OMAP3 supports BCH ECC scheme. Document: http://www.ti.com/lit/pdf/spruf98 (1) GPMC in OMAP3 supports BCH8 Section: 11.1.5.14.3.2 BCH Code (2) ROM code in GPMC supports BCH (but its not clear whether its BCH4 or BCH8) Section: 25.4.7.4.3 MLC NAND Read Sector Procedure No, ROM code on OMAP3 doesn't support standard BCH but its own proprietary scheme which combines BCH checksum and other redundancy techniques, which means that MLC NAND is not recommended to be used as boot media for OMAP3. cheers, -roger But I agree that now it doesn't make sense to put effort on OMAP3 for upgrading default ECC schemes. If user has to migrate then there are other easy ways of doing so. Then there is the question of boot rom compatibility. OMAP3 bootloaders use HAM1 scheme. So if you want to be able to flash bootloader from the kernel we have to stick with HAM1. changing the ECC scheme would mean that NAND filesystems created earlier won't work and will have to be erased and recreated. Right. I doubt anybody has bch8 rootfs on LDP.. And considering u-boot must be ham1 to boot at all, that's what we should change for the devices that do not have not standardized on bch8. My view on this is slightly different: - Lately, everyone seems to have migrated to BCH8. - Also HAM1 does not have strength to fix bitflips in aging NAND. So if someone already has OMAP3-LDP deployed on field then its NAND would have already aged to such an extend that HAM1 may not be sufficient. My question is.. Moving back to HAM1 should be decided based on statistics rather than rule of breaking backward compatibility. So please review: (1) How many user of OMAP3-Zoom or other old boards complaining about using BCH8 in mainline kernel? OR (2) How many users of OMAP3 legacy boards are migrating to newer kernel? At-least I have not, rather most of the OMAP3 users I interacted via TI's E2E forum wanted to migrate to BCH8 or even BCH16, as HAM1 was not sufficient for their usage. So whatever you decide on this topic, please be cautious that you don't re-invent work for yourself, as I did. It took me lot of time and testing effort on multiple boards to migrate HAM1 to BCH8, And add BCH16 for newer devices. Also, now I realize u-boot (boot-loaders) are better place for all this migration. Regards, Tony with regards, pekon Powered by BigRock.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 v4 4/8] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 11/13/2014 01:09 PM, Marc Kleine-Budde wrote: On 11/07/2014 03:49 PM, Roger Quadros wrote: Some TI SoCs like DRA7 have a RAMINIT register specification different from the other AMxx SoCs and as expected by the existing driver. To add more insanity, this register is shared with other IPs like DSS, PCIe and PWM. Provides a more generic mechanism to specify the RAMINIT register location and START/DONE bit position and use the syscon/regmap framework to access the register. What about the existing device trees that don't have the syscon-raminit phandle? We can either keep the existing init routines or create regmap in the platform driver an use the new ones. There is only one user arch/arm/boot/dts/am33xx.dtsi The can nodes are disabled there and no other board file is enabling that node. So there is no breakage as such and not worth the hassle to maintain the old routine. I will be sending the corresponding dts changes today which Tony will take as we don't see any DT binding changes. cheers, -roger -- 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 v4 02/10] ARM: dts: DRA7: Add DCAN nodes
The SoC supports 2 DCAN nodes. Add them.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5fd52cd..631b5fb 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -34,6 +34,8 @@
serial3 = uart4;
serial4 = uart5;
serial5 = uart6;
+ d_can0 = dcan1;
+ d_can1 = dcan2;
};
timer {
@@ -1270,6 +1272,26 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+ dcan1: can@481cc000 {
+ compatible = ti,dra7-d_can;
+ ti,hwmods = dcan1;
+ reg = 0x4ae3c000 0x2000;
+ syscon-raminit = dra7_ctrl_core 0x558 0;
+ interrupts = GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH;
+ clocks = dcan1_sys_clk_mux;
+ status = disabled;
+ };
+
+ dcan2: can@481d {
+ compatible = ti,dra7-d_can;
+ ti,hwmods = dcan2;
+ reg = 0x4848 0x2000;
+ syscon-raminit = dra7_ctrl_core 0x558 1;
+ interrupts = GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH;
+ clocks = sys_clkin1;
+ status = disabled;
+ };
};
};
--
1.8.3.2
--
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 v4 00/10] ARM: dts: TI: Add CAN support
Hi Tony, These patches add CAN support for am33xx, am43xx and dra7 platforms. They can go in independent of [1] but depend on [1] for functionality. Tested on am335x-evm, am437x-gp-evm and dra7-evm. NOTE: - for DCAN to work on DRA7 we need this patch to keep the CAN PHY powered. https://lkml.org/lkml/2014/10/21/484 - on DRA7 there is another issue which causes undesired behaviour if WKUPAON and L4CFG clock domains are allowed to HW_AUTO. Undesired behaviour is in the form of DCAN1 module being stuck-in-transition when disabled and RAMINIT-done bit not getting set as part of RAMINIT mechanism. To address these issues there is a patch to prevent these clockdomains from HW_AUTO. https://github.com/rogerq/linux/commit/31d6da939dbbaf8ea2ab96ca5680b81cd5607e51 Even without this second patch DCAN seems to work. cheers, -roger Changelog: v4: - added CAN instance number to syscon-raminit and use new compatible ids v3: - Move raminit register data into driver data - rename syscon property to syscon-raminit v2: - Added vendor prefix ti, to raminit properties - Updated am335x dcan nodes [1] - CAN driver RAMINIT Syscon support http://article.gmane.org/gmane.linux.can/6892 cheers, -roger --- Mugunthan V N (1): arm: dts: am437x-gp: Add dcan support Roger Quadros (9): ARM: dts: dra7: Add syscon regmap for CORE CONTROL area ARM: dts: DRA7: Add DCAN nodes ARM: dts: dra7-evm: Add CAN support ARM: dts: dra72-evm: Add CAN support ARM: dts: am4372: Add control module syscon node ARM: dts: am4372: Add DCAN nodes ARM: dts: am33xx: Add control module syscon node ARM: dts: am33xx: Update DCAN nodes ARM: dts: am335x-evm: Add DCAN1 details arch/arm/boot/dts/am335x-evm.dts| 13 + arch/arm/boot/dts/am33xx.dtsi | 25 + arch/arm/boot/dts/am4372.dtsi | 27 +++ arch/arm/boot/dts/am437x-gp-evm.dts | 26 ++ arch/arm/boot/dts/dra7-evm.dts | 23 +++ arch/arm/boot/dts/dra7.dtsi | 27 +++ arch/arm/boot/dts/dra72-evm.dts | 23 +++ 7 files changed, 156 insertions(+), 8 deletions(-) -- 1.8.3.2 -- 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 v4 03/10] ARM: dts: dra7-evm: Add CAN support
The board has 2 CAN ports but only the first one can be used.
Enable the first CAN port.
WAKEUP0 pin doesn't have INPUT enable bit so we just disable
weak PULLs.
The second CAN port cannot be used without hardware modification
so we don't enable the second port.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index c6ce625..8c2c37b 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -171,6 +171,22 @@
0xd0(PIN_OUTPUT | MUX_MODE0)/*
gpmc_be0n_cle */
;
};
+
+ dcan1_pins_default: dcan1_pins_default {
+ pinctrl-single,pins =
+ 0x3d0 (PIN_OUTPUT | MUX_MODE0) /* dcan1_tx */
+ 0x3d4 (MUX_MODE15)/* dcan1_rx.off */
+ 0x418 (PULL_DIS | MUX_MODE1) /* wakeup0.dcan1_rx */
+ ;
+ };
+
+ dcan1_pins_sleep: dcan1_pins_sleep {
+ pinctrl-single,pins =
+ 0x3d0 (MUX_MODE15)/* dcan1_tx.off */
+ 0x3d4 (MUX_MODE15)/* dcan1_rx.off */
+ 0x418 (MUX_MODE15)/* wakeup0.off */
+ ;
+ };
};
i2c1 {
@@ -528,3 +544,10 @@
ti,no-reset-on-init;
ti,no-idle-on-init;
};
+
+dcan1 {
+ status = ok;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = dcan1_pins_default;
+ pinctrl-1 = dcan1_pins_sleep;
+};
--
1.8.3.2
--
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 v4 05/10] ARM: dts: am4372: Add control module syscon node
Use syscon regmap to expose the Control module register space.
This register space is shared between many users e.g. DCAN, USB, display, etc.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 46660ff..899c57c 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -57,6 +57,11 @@
cache-level = 2;
};
+ am43xx_control_module: control_module@4a002000 {
+ compatible = syscon;
+ reg = 0x44e1 0x7f4;
+ };
+
am43xx_pinmux: pinmux@44e10800 {
compatible = ti,am437-padconf, pinctrl-single;
reg = 0x44e10800 0x31c;
--
1.8.3.2
--
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 v4 07/10] arm: dts: am437x-gp: Add dcan support
From: Mugunthan V N mugunthan...@ti.com
Add DCAN support for AM437x GP EVM with both DCAN instances.
[Roger Q] Updated output pin to not use pull up.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index e7ac47f..58594fd 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -254,6 +254,20 @@
0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
;
};
+
+ dcan0_default: dcan0_default_pins {
+ pinctrl-single,pins =
+ 0x178 (PIN_OUTPUT | MUX_MODE2) /*
uart1_ctsn.d_can0_tx */
+ 0x17c (PIN_INPUT_PULLUP | MUX_MODE2)/*
uart1_rtsn.d_can0_rx */
+ ;
+ };
+
+ dcan1_default: dcan1_default_pins {
+ pinctrl-single,pins =
+ 0x180 (PIN_OUTPUT | MUX_MODE2) /*
uart1_rxd.d_can1_tx */
+ 0x184 (PIN_INPUT_PULLUP | MUX_MODE2)/*
uart1_txd.d_can1_rx */
+ ;
+ };
};
i2c0 {
@@ -511,3 +525,15 @@
};
};
};
+
+dcan0 {
+ pinctrl-names = default;
+ pinctrl-0 = dcan0_default;
+ status = okay;
+};
+
+dcan1 {
+ pinctrl-names = default;
+ pinctrl-0 = dcan1_default;
+ status = okay;
+};
--
1.8.3.2
--
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 v4 08/10] ARM: dts: am33xx: Add control module syscon node
Use syscon regmap to expose the Control module register space.
This register space is shared between many users e.g. DCAN, USB, display, etc.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 8318105..9f3058c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -83,6 +83,11 @@
};
};
+ am33xx_control_module: control_module@4a002000 {
+ compatible = syscon;
+ reg = 0x44e1 0x7fc;
+ };
+
am33xx_pinmux: pinmux@44e10800 {
compatible = pinctrl-single;
reg = 0x44e10800 0x0238;
--
1.8.3.2
--
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 v4 01/10] ARM: dts: dra7: Add syscon regmap for CORE CONTROL area
Display and DCAN drivers use syscon regmap to access some registers
in the CORE control area. Add the syscon regmap node for this
area.
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9cc9843..5fd52cd 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -201,6 +201,11 @@
ti,hwmods = counter_32k;
};
+ dra7_ctrl_core: ctrl_core@4a002000 {
+ compatible = syscon;
+ reg = 0x4a002000 0x6d0;
+ };
+
dra7_ctrl_general: tisyscon@4a002e00 {
compatible = syscon;
reg = 0x4a002e00 0x7c;
--
1.8.3.2
--
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 v4 04/10] ARM: dts: dra72-evm: Add CAN support
The board has 2 CAN ports but only the first one can be used.
Enable the first CAN port.
WAKEUP0 pin doesn't have INPUT enable bit so we just disable
weak PULLs.
The second CAN port cannot be used without hardware modification
so we don't enable the second port.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra72-evm.dts | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 4107428..a4b01ce 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -26,6 +26,22 @@
0x404 (PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */
;
};
+
+ dcan1_pins_default: dcan1_pins_default {
+ pinctrl-single,pins =
+ 0x3d0 (PIN_OUTPUT | MUX_MODE0) /* dcan1_tx */
+ 0x3d4 (MUX_MODE15)/* dcan1_rx.off */
+ 0x418 (PULL_DIS | MUX_MODE1) /* wakeup0.dcan1_rx */
+ ;
+ };
+
+ dcan1_pins_sleep: dcan1_pins_sleep {
+ pinctrl-single,pins =
+ 0x3d0 (MUX_MODE15)/* dcan1_tx.off */
+ 0x3d4 (MUX_MODE15)/* dcan1_rx.off */
+ 0x418 (MUX_MODE15)/* wakeup0.off */
+ ;
+ };
};
i2c1 {
@@ -142,3 +158,10 @@
uart1 {
status = okay;
};
+
+dcan1 {
+ status = ok;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = dcan1_pins_default;
+ pinctrl-1 = dcan1_pins_sleep;
+};
--
1.8.3.2
--
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 v4 10/10] ARM: dts: am335x-evm: Add DCAN1 details
DCAN1 is routed to CAN port (J11) when Profile 1 is selected on the
profile selection switch.
Provide information for DCAN1 pins and node but keep it disabled
by default. User has to manually enable it if Profile 1 is chosen.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e2156a5..e3d0b39 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -307,6 +307,13 @@
0x144 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
rmii1_ref_clk.mcasp1_axr3 */
;
};
+
+ dcan1_pins_default: dcan1_pins_default {
+ pinctrl-single,pins =
+ 0x168 (PIN_OUTPUT | MUX_MODE2) /* uart0_ctsn.d_can1_tx
*/
+ 0x16c (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
uart0_rtsn.d_can1_rx */
+ ;
+ };
};
uart0 {
@@ -664,3 +671,9 @@
aes {
status = okay;
};
+
+dcan1 {
+ status = disabled;/* Enable only if Profile 1 is selected */
+ pinctrl-names = default;
+ pinctrl-0 = dcan1_pins_default;
+};
--
1.8.3.2
--
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 v4 06/10] ARM: dts: am4372: Add DCAN nodes
The SoC contains 2 DCAN modules. Add them.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 899c57c..12fb1db 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -901,6 +901,28 @@
compatible = mmio-sram;
reg = 0x4030 0x4; /* 256k */
};
+
+ dcan0: can@481cc000 {
+ compatible = ti,am3352-d_can;
+ ti,hwmods = d_can0;
+ clocks = dcan0_fck;
+ clock-names = fck;
+ reg = 0x481cc000 0x2000;
+ syscon-raminit = am43xx_control_module 0x644 0;
+ interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
+ dcan1: can@481d {
+ compatible = ti,am3352-d_can;
+ ti,hwmods = d_can1;
+ clocks = dcan1_fck;
+ clock-names = fck;
+ reg = 0x481d 0x2000;
+ syscon-raminit = am43xx_control_module 0x644 1;
+ interrupts = GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
};
};
--
1.8.3.2
--
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 v4 09/10] ARM: dts: am33xx: Update DCAN nodes
Add raminit-syscon property to specify the RAMINIT register.
Add clock information.
Rename can nodes from d_can to can to be compliant
with the ePAPR specs.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9f3058c..74fefa1 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -338,20 +338,24 @@
interrupts = 91;
};
- dcan0: d_can@481cc000 {
- compatible = bosch,d_can;
+ dcan0: can@481cc000 {
+ compatible = ti,am3352-d_can;
ti,hwmods = d_can0;
- reg = 0x481cc000 0x2000
- 0x44e10644 0x4;
+ reg = 0x481cc000 0x2000;
+ clocks = dcan0_fck;
+ clock-names = fck;
+ syscon-raminit = am33xx_control_module 0x644 0;
interrupts = 52;
status = disabled;
};
- dcan1: d_can@481d {
- compatible = bosch,d_can;
+ dcan1: can@481d {
+ compatible = ti,am3352-d_can;
ti,hwmods = d_can1;
- reg = 0x481d 0x2000
- 0x44e10644 0x4;
+ reg = 0x481d 0x2000;
+ clocks = dcan1_fck;
+ clock-names = fck;
+ syscon-raminit = am33xx_control_module 0x644 1;
interrupts = 55;
status = disabled;
};
--
1.8.3.2
--
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 0/4] Touchscreen performance related fixes
Hi, On Wednesday 12 November 2014 06:30 PM, Johannes Pointner wrote: Hello Vignesh, I tried your patch version 3 on a customized board and had some behavior I couldn't explain. If I only use the touchscreen it works fine but if I also read values from the ADCs then I get a lot of pen_up events even if I am still touching the screen. For the test I read via # cat /sys/bus/iio/devices/iio\:device0/in_voltage5_raw values from the ADC in an busy loop as you explained in an email before. Did you also experience such behavior or do you know what causes it? Thanks for testing. I was able to fix this issue. Will post version 4 shortly. Regards Vignesh Without the patches the touchscreen works fine during the iio test. Thanks, Hannes 2014-11-06 8:42 GMT+01:00 Vignesh R vigne...@ti.com: On Monday 03 November 2014 11:39 PM, Richard Cochran wrote: On Mon, Oct 27, 2014 at 04:38:27PM +0530, Vignesh R wrote: This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement Advisory 1.0.31 in silicon errata of am335x-evm to avoid false pen-up events and remove udelay. That advisory has two workarounds. You have chosen the second one? Work around one. Hence 5 wire design is not broken. The text of the second workaround says it only works on 4 wire setups, so I wonder how 5 wire designs will be affected. The advisory says to use steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel ADC). No, it doesn't say that. (sprz360f.pdf) The pen up event detection happens immediately after charge step. Hence, interchanging ADC and TSC steps makes sure that sampling of touch co-ordinates and pen events are done one after the other. This workaround was suggested by internal hardware folks. Earlier ADC steps intervened between sampling of co-ordinates and pen event detection which is not desirable. Further the X co-ordinate must be the last one to be sampled just before charge step. The first two patches implement the required changes. FWIW, I implemented the first workaround and removed the udelay not too long ago. Like Sebastian, I saw the TSC unit hang after about 5 interrupts when running with the workaround. Did you test you patch for very long? Yes, I tested for about 20 interrupts and I didn't see any hang. This patch series does not just implement workaround but also does some minor changes, such as interchanging ADC and TSC steps etc, which makes TSC driver more robust. Let me know if you encounter any issues with my patch series. Regards Vignesh Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-iio in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.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: [PATCH v4 4/8] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 11/07/2014 03:49 PM, Roger Quadros wrote:
Some TI SoCs like DRA7 have a RAMINIT register specification
different from the other AMxx SoCs and as expected by the
existing driver.
To add more insanity, this register is shared with other
IPs like DSS, PCIe and PWM.
Provides a more generic mechanism to specify the RAMINIT
register location and START/DONE bit position and use the
syscon/regmap framework to access the register.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/net/can/c_can.txt | 3 +
drivers/net/can/c_can/c_can.h | 11 +-
drivers/net/can/c_can/c_can_platform.c | 112
++---
3 files changed, 86 insertions(+), 40 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt
b/Documentation/devicetree/bindings/net/can/c_can.txt
index 8f1ae81..a3ca3ee 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -12,6 +12,9 @@ Required properties:
Optional properties:
- ti,hwmods : Must be d_cann or c_cann, n being the
instance number
+- syscon-raminit : Handle to system control region that contains the
+ RAMINIT register, register offset to the RAMINIT
+ register and the CAN instance number (0 offset).
Note: ti,hwmods field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 3c305a1..0e17c7b 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -179,6 +179,14 @@ struct c_can_driver_data {
bool raminit_pulse; /* If set, sets and clears START bit (pulse) */
};
+/* Out of band RAMINIT register access via syscon regmap */
+struct c_can_raminit {
+ struct regmap *syscon; /* for raminit ctrl. reg. access */
+ unsigned int reg; /* register index within syscon */
+ u8 start_bit;
+ u8 done_bit;
+};
+
/* c_can private data structure */
struct c_can_priv {
struct can_priv can;/* must be the first member */
@@ -196,8 +204,7 @@ struct c_can_priv {
const u16 *regs;
void *priv; /* for board-specific data */
enum c_can_dev_id type;
- u32 __iomem *raminit_ctrlreg;
- int instance;
+ struct c_can_raminit raminit_sys; /* RAMINIT via syscon regmap */
void (*raminit) (const struct c_can_priv *priv, bool enable);
u32 comm_rcv_high;
u32 rxmasked;
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index 20deb67..3776483 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,14 +32,13 @@
#include linux/clk.h
#include linux/of.h
#include linux/of_device.h
+#include linux/mfd/syscon.h
+#include linux/regmap.h
#include linux/can/dev.h
#include c_can.h
-#define CAN_RAMINIT_START_MASK(i)(0x001 (i))
-#define CAN_RAMINIT_DONE_MASK(i) (0x100 (i))
-#define CAN_RAMINIT_ALL_MASK(i) (0x101 (i))
#define DCAN_RAM_INIT_BIT(1 3)
static DEFINE_SPINLOCK(raminit_lock);
/*
@@ -72,47 +71,61 @@ static void c_can_plat_write_reg_aligned_to_32bit(const
struct c_can_priv *priv,
writew(val, priv-base + 2 * priv-regs[index]);
}
-static void c_can_hw_raminit_wait_ti(const struct c_can_priv *priv, u32 mask,
- u32 val)
+static void c_can_hw_raminit_wait_syscon(const struct c_can_priv *priv,
+ u32 mask, u32 val)
{
int timeout = 0;
+ const struct c_can_raminit *raminit = priv-raminit_sys;
+ u32 ctrl;
+
/* We look only at the bits of our instance. */
val = mask;
- while ((readl(priv-raminit_ctrlreg) mask) != val) {
+ do {
udelay(1);
timeout++;
+ regmap_read(raminit-syscon, raminit-reg, ctrl);
if (timeout == 1000) {
dev_err(priv-dev-dev, %s: time out\n, __func__);
break;
}
- }
+ } while ((ctrl mask) != val);
}
-static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
+static void c_can_hw_raminit_syscon(const struct c_can_priv *priv, bool
enable)
{
- u32 mask = CAN_RAMINIT_ALL_MASK(priv-instance);
+ u32 mask;
u32 ctrl;
+ const struct c_can_raminit *raminit = priv-raminit_sys;
+ u8 start_bit, done_bit;
+
+ start_bit = raminit-start_bit;
+ done_bit = raminit-done_bit;
spin_lock(raminit_lock);
- ctrl = readl(priv-raminit_ctrlreg);
+ mask = 1 start_bit | 1 done_bit;
+ regmap_read(raminit-syscon, raminit-reg, ctrl);
+
/* We clear the done and
Re: [PATCH v5 6/8] net: can: c_can: Disable pins when CAN interface is down
On 11/12/2014 03:16 PM, Roger Quadros wrote:
DRA7 CAN IP suffers from a problem which causes it to be prevented
from fully turning OFF (i.e. stuck in transition) if the module was
disabled while there was traffic on the CAN_RX line.
To work around this issue we select the SLEEP pin state by default
on probe and use the DEFAULT pin state on CAN up and back to the
SLEEP pin state on CAN down.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/net/can/c_can/c_can.c | 21 +
drivers/net/can/c_can/c_can.h | 1 +
drivers/net/can/c_can/c_can_platform.c | 20
3 files changed, 42 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 8e78bb4..a950eea 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -35,6 +35,7 @@
#include linux/list.h
#include linux/io.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
#include linux/can.h
#include linux/can/dev.h
@@ -587,6 +588,21 @@ static int c_can_chip_config(struct net_device *dev)
return c_can_set_bittiming(dev);
}
+/*
+ * Selects the pinctrl state specified in the name.
+ */
+static void c_can_pinctrl_select_state(struct c_can_priv *priv,
+ const char *name)
+{
+ if (!IS_ERR(priv-pinctrl)) {
What happens if priv-pinctrl is NULL? This is probably the case with
the c_can_pci driver.
+ struct pinctrl_state *s;
+
+ s = pinctrl_lookup_state(priv-pinctrl, name);
+ if (!IS_ERR(s))
+ pinctrl_select_state(priv-pinctrl, s);
+ }
+}
+
static int c_can_start(struct net_device *dev)
{
struct c_can_priv *priv = netdev_priv(dev);
@@ -603,6 +619,8 @@ static int c_can_start(struct net_device *dev)
priv-can.state = CAN_STATE_ERROR_ACTIVE;
+ /* activate pins */
+ c_can_pinctrl_select_state(priv, PINCTRL_STATE_DEFAULT);
return 0;
}
@@ -611,6 +629,9 @@ static void c_can_stop(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
c_can_irq_control(priv, false);
+
+ /* deactivate pins */
+ c_can_pinctrl_select_state(priv, PINCTRL_STATE_SLEEP);
priv-can.state = CAN_STATE_STOPPED;
}
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index c6715ca..3cedf48 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -210,6 +210,7 @@ struct c_can_priv {
u32 comm_rcv_high;
u32 rxmasked;
u32 dlc[C_CAN_MSG_OBJ_TX_NUM];
+ struct pinctrl *pinctrl;
};
struct net_device *alloc_c_can_dev(void);
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index b838c6b..71b9063 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -34,6 +34,7 @@
#include linux/of_device.h
#include linux/mfd/syscon.h
#include linux/regmap.h
+#include linux/pinctrl/consumer.h
#include linux/can/dev.h
@@ -230,6 +231,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
struct clk *clk;
const struct c_can_driver_data *drvdata;
struct device_node *np = pdev-dev.of_node;
+ struct pinctrl *pinctrl;
match = of_match_device(c_can_of_table, pdev-dev);
if (match) {
@@ -241,6 +243,23 @@ static int c_can_plat_probe(struct platform_device *pdev)
return -ENODEV;
}
+ pinctrl = devm_pinctrl_get(pdev-dev);
+ if (!IS_ERR(pinctrl)) {
+ struct pinctrl_state *s;
+
+ /* Deactivate pins to prevent DRA7 DCAN IP from being
+ * stuck in transition when module is disabled.
+ * Pins are activated in c_can_start() and deactivated
+ * in c_can_stop()
+ */
+ s = pinctrl_lookup_state(pinctrl, PINCTRL_STATE_SLEEP);
+ if (!IS_ERR(s))
+ pinctrl_select_state(pinctrl, s);
+ } else {
+ dev_warn(pdev-dev,
+ failed to get pinctrl\n);
+ }
Can you move the initial setting into c_can.c, register_c_can_dev()
should be a good candidate.
+
/* get the appropriate clk */
clk = devm_clk_get(pdev-dev, NULL);
if (IS_ERR(clk)) {
@@ -270,6 +289,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
}
priv = netdev_priv(dev);
+ priv-pinctrl = pinctrl;
switch (drvdata-id) {
case BOSCH_C_CAN:
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
[RFC PATCH 0/3] DRA72: MMC HS200 support
Added HS200 to improve EMMC throughput for dra72. With HS200 == Read throughput ./dd if=/dev/mmcblk0 of=/dev/null bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 1.46028 s, 71.8 MB/s Write throughput root@dra7xx-evm:/# ./dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 9.34884 s, 11.2 MB/s WithOUT HS200 == Read throughput ./dd if=/dev/mmcblk0 of=/dev/null bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 2.6423 s, 39.7 MB/s Write throughput ./dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 9.3556 s, 11.2 MB/s Balaji T K (1): mmc: omap_hsmmc: add tuning support Kishon Vijay Abraham I (1): ARM: dts: dra72-evm: Set the max-frequency to 192MHz Viswanath Puttagunta (1): mmc: omap_hsmmc: set host capabilities by reading MMCHS_CAPA2 register arch/arm/boot/dts/dra72-evm.dts |1 + drivers/mmc/host/omap_hsmmc.c | 342 ++- 2 files changed, 341 insertions(+), 2 deletions(-) -- 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
[RFC PATCH 0/3] DRA72: MMC HS200 support
Added HS200 to improve EMMC throughput for dra72. With HS200 == Read throughput ./dd if=/dev/mmcblk0 of=/dev/null bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 1.46028 s, 71.8 MB/s Write throughput root@dra7xx-evm:/# ./dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 9.34884 s, 11.2 MB/s WithOUT HS200 == Read throughput ./dd if=/dev/mmcblk0 of=/dev/null bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 2.6423 s, 39.7 MB/s Write throughput ./dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 9.3556 s, 11.2 MB/s Balaji T K (1): mmc: omap_hsmmc: add tuning support Kishon Vijay Abraham I (1): ARM: dts: dra72-evm: Set the max-frequency to 192MHz Viswanath Puttagunta (1): mmc: omap_hsmmc: set host capabilities by reading MMCHS_CAPA2 register arch/arm/boot/dts/dra72-evm.dts |1 + drivers/mmc/host/omap_hsmmc.c | 342 ++- 2 files changed, 341 insertions(+), 2 deletions(-) -- 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
[RFC PATCH 2/3] mmc: omap_hsmmc: add tuning support
From: Balaji T K balaj...@ti.com
MMC tuning procedure is required to support SD card
UHS1-SDR104 mode and EMMC HS200 mode.
The tuning function omap_execute_tuning() will only
be called by the MMC/SD core if the corresponding
speed modes are supported by the OMAP silicon which
is set in the mmc host caps field.
Signed-off-by: Viswanath Puttagunta vi...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
[ kis...@ti.com : Set the functional clock to 192MHz if the contoller
supports HS200 ]
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 325 -
1 file changed, 322 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2e42ed3..675bd31d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -22,6 +22,7 @@
#include linux/dmaengine.h
#include linux/seq_file.h
#include linux/sizes.h
+#include linux/slab.h
#include linux/interrupt.h
#include linux/delay.h
#include linux/dma-mapping.h
@@ -47,6 +48,7 @@
/* OMAP HSMMC Host Controller Registers */
#define OMAP_HSMMC_SYSSTATUS 0x0014
#define OMAP_HSMMC_CON 0x002C
+#define OMAP_HSMMC_DLL 0x0034
#define OMAP_HSMMC_SDMASA 0x0100
#define OMAP_HSMMC_BLK 0x0104
#define OMAP_HSMMC_ARG 0x0108
@@ -100,6 +102,7 @@
#define CLKEXTFREE (1 16)
#define CTPL (1 11)
#define DW8(1 5)
+#define BRR(1 5)
#define OD 0x1
#define STAT_CLEAR 0x
#define INIT_STREAM_CMD0x
@@ -129,6 +132,20 @@
#define CERR_EN(1 28)
#define BADA_EN(1 29)
+#define V1V8_SIGEN (1 19)
+#define AC12_SCLK_SEL (1 23)
+#define AC12_UHSMC_MASK(7 16)
+#define AC12_UHSMC_SDR50 (2 16)
+#define AC12_UHSMC_SDR104 (3 16)
+#define DLL_LOCK (1 0)
+#define DLL_CALIB (1 1)
+#define DLL_UNLOCK_STICKY (1 2)
+#define DLL_SWT(1 20)
+#define DLL_FORCE_SR_C_MASK(0x7F 13)
+#define DLL_FORCE_SR_C_SHIFT 13
+#define DLL_FORCE_VALUE(1 12)
+#define DLL_RESET (1 31)
+
#define INT_EN_MASK (BADA_EN | CERR_EN | ACE_EN | DEB_EN | DCRC_EN |\
DTO_EN | CIE_EN | CEB_EN | CCRC_EN | CTO_EN | \
BRR_EN | BWR_EN | TC_EN | CC_EN)
@@ -143,18 +160,23 @@
#define SDR50 (1 0)
#define SDR104 (1 1)
#define DDR50 (1 2)
+#define CAPA2_TSDR50 (1 13)
#define MMC_AUTOSUSPEND_DELAY 100
#define MMC_TIMEOUT_MS 20 /* 20 mSec */
#define MMC_TIMEOUT_US 2 /* 2 micro Sec */
#define OMAP_MMC_MIN_CLOCK 40
#define OMAP_MMC_MAX_CLOCK 5200
+#define MAX_PHASE_DELAY0x7F
#define DRIVER_NAMEomap_hsmmc
#define VDD_1V8180 /* 18 uV */
#define VDD_3V0300 /* 30 uV */
#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
+#define EMMC_HSDDR_SD_SDR25_MAX5200
+#define SD_SDR50_MAX_FREQ 10400
+
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -198,6 +220,7 @@ struct omap_hsmmc_host {
void__iomem *base;
resource_size_t mapbase;
spinlock_t irq_lock; /* Prevent races with irq handler */
+ struct completion buf_ready;
unsigned intdma_len;
unsigned intdma_sg_idx;
unsigned char bus_mode;
@@ -224,6 +247,13 @@ struct omap_hsmmc_host {
#define AUTO_CMD23 (1 0)/* Auto CMD23 support */
#define HSMMC_SDIO_IRQ_ENABLED (1 1)/* SDIO irq enabled */
#define HSMMC_WAKE_IRQ_ENABLED (1 2)
+
+ u32 *tuning_data;
+ int tuning_size;
+ int tuning_done;
+ int tuning_fsrc;
+ u32 tuning_uhsmc;
+ u32 tuning_opcode;
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -233,6 +263,48 @@ struct omap_mmc_of_data {
u8 controller_flags;
};
+static const u32 ref_tuning_4bits[] = {
+ 0x00FF0FFF, 0xCCC3CCFF, 0xFFCC3CC3, 0xEFFEFFFE,
+ 0xDDFFDFFF, 0xFBFFFBFF, 0xFF7FFFBF, 0xEFBDF777,
+ 0xF0FFF0FF, 0x3CCCFC0F, 0xCFCC33CC, 0xEEFFEFFF,
+ 0xFDFFFDFF, 0xFFBFFFDF, 0xFFF7FFBB, 0xDE7B7FF7
+};
+
+static const u32 ref_tuning_8bits[] = {
+ 0xFF00, 0x, 0x, 0x33CC,
+ 0xCCCC, 0x, 0xEEFF, 0xFFFF,
+ 0xFFDD, 0x, 0xBBFF, 0xBBFF,
+
Re: [PATCH v4 4/8] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 11/13/2014 01:09 PM, Roger Quadros wrote: What about the existing device trees that don't have the syscon-raminit phandle? We can either keep the existing init routines or create regmap in the platform driver an use the new ones. There is only one user arch/arm/boot/dts/am33xx.dtsi The can nodes are disabled there and no other board file is enabling that node. So there is no breakage as such and not worth the hassle to maintain the old routine. I will be sending the corresponding dts changes today which Tony will take as we don't see any DT binding changes. Alright then (I'll give your email to $CUSTOMERS complaining ;) ), this whole series will go into 3.19. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
[RFC PATCH 3/3] ARM: dts: dra72-evm: Set the max-frequency to 192MHz
Set the maximum operating frequency of MMC2 to 192MHz.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/dra72-evm.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index abbaaa7..5cc1110 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -364,6 +364,7 @@
vmmc-supply = evm_3v3;
bus-width = 8;
ti,non-removable;
+ max-frequency = 19200;
};
dra7_pmx_core {
--
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
[RFC PATCH 1/3] mmc: omap_hsmmc: set host capabilities by reading MMCHS_CAPA2 register
From: Viswanath Puttagunta vi...@ti.com
set SDR104, SDR50, DDR50 and HS200 capability flags to caps/caps2 by reading
MMCHS_CAPA2 register.
Signed-off-by: Viswanath Puttagunta vi...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Suggested-by: Misael Lopez Cruz misael.lo...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index df27bb4..2e42ed3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -64,6 +64,7 @@
#define OMAP_HSMMC_ISE 0x0138
#define OMAP_HSMMC_AC120x013C
#define OMAP_HSMMC_CAPA0x0140
+#define OMAP_HSMMC_CAPA2 0x0144
#define VS18 (1 26)
#define VS30 (1 25)
@@ -139,6 +140,10 @@
#define ACTO (1 1)
#define ACNE (1 0)
+#define SDR50 (1 0)
+#define SDR104 (1 1)
+#define DDR50 (1 2)
+
#define MMC_AUTOSUSPEND_DELAY 100
#define MMC_TIMEOUT_MS 20 /* 20 mSec */
#define MMC_TIMEOUT_US 2 /* 2 micro Sec */
@@ -2028,6 +2033,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
unsigned tx_req, rx_req;
const struct omap_mmc_of_data *data;
void __iomem *base;
+ u32 reg;
match = of_match_device(of_match_ptr(omap_mmc_of_match), pdev-dev);
if (match) {
@@ -2153,6 +2159,19 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
mmc-pm_caps = mmc_slot(host).pm_caps;
+ reg = OMAP_HSMMC_READ(host-base, OMAP_HSMMC_CAPA2);
+
+ if (reg SDR50)
+ mmc-caps |= MMC_CAP_UHS_DDR50;
+
+ if (reg SDR104) {
+ mmc-caps |= MMC_CAP_UHS_SDR104;
+ mmc-caps2 |= MMC_CAP2_HS200;
+ }
+
+ if (reg DDR50)
+ mmc-caps |= MMC_CAP_UHS_DDR50;
+
omap_hsmmc_conf_bus_power(host);
if (!pdev-dev.of_node) {
--
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
Re: [PATCH v5 6/8] net: can: c_can: Disable pins when CAN interface is down
On 11/13/2014 02:56 PM, Marc Kleine-Budde wrote:
On 11/12/2014 03:16 PM, Roger Quadros wrote:
DRA7 CAN IP suffers from a problem which causes it to be prevented
from fully turning OFF (i.e. stuck in transition) if the module was
disabled while there was traffic on the CAN_RX line.
To work around this issue we select the SLEEP pin state by default
on probe and use the DEFAULT pin state on CAN up and back to the
SLEEP pin state on CAN down.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/net/can/c_can/c_can.c | 21 +
drivers/net/can/c_can/c_can.h | 1 +
drivers/net/can/c_can/c_can_platform.c | 20
3 files changed, 42 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 8e78bb4..a950eea 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -35,6 +35,7 @@
#include linux/list.h
#include linux/io.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
#include linux/can.h
#include linux/can/dev.h
@@ -587,6 +588,21 @@ static int c_can_chip_config(struct net_device *dev)
return c_can_set_bittiming(dev);
}
+/*
+ * Selects the pinctrl state specified in the name.
+ */
+static void c_can_pinctrl_select_state(struct c_can_priv *priv,
+ const char *name)
+{
+if (!IS_ERR(priv-pinctrl)) {
What happens if priv-pinctrl is NULL? This is probably the case with
the c_can_pci driver.
There will be a NULL pointer dereference error. :(
+struct pinctrl_state *s;
+
+s = pinctrl_lookup_state(priv-pinctrl, name);
+if (!IS_ERR(s))
+pinctrl_select_state(priv-pinctrl, s);
+}
+}
+
static int c_can_start(struct net_device *dev)
{
struct c_can_priv *priv = netdev_priv(dev);
@@ -603,6 +619,8 @@ static int c_can_start(struct net_device *dev)
priv-can.state = CAN_STATE_ERROR_ACTIVE;
+/* activate pins */
+c_can_pinctrl_select_state(priv, PINCTRL_STATE_DEFAULT);
return 0;
}
@@ -611,6 +629,9 @@ static void c_can_stop(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
c_can_irq_control(priv, false);
+
+/* deactivate pins */
+c_can_pinctrl_select_state(priv, PINCTRL_STATE_SLEEP);
priv-can.state = CAN_STATE_STOPPED;
}
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index c6715ca..3cedf48 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -210,6 +210,7 @@ struct c_can_priv {
u32 comm_rcv_high;
u32 rxmasked;
u32 dlc[C_CAN_MSG_OBJ_TX_NUM];
+struct pinctrl *pinctrl;
};
struct net_device *alloc_c_can_dev(void);
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index b838c6b..71b9063 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -34,6 +34,7 @@
#include linux/of_device.h
#include linux/mfd/syscon.h
#include linux/regmap.h
+#include linux/pinctrl/consumer.h
#include linux/can/dev.h
@@ -230,6 +231,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
struct clk *clk;
const struct c_can_driver_data *drvdata;
struct device_node *np = pdev-dev.of_node;
+struct pinctrl *pinctrl;
match = of_match_device(c_can_of_table, pdev-dev);
if (match) {
@@ -241,6 +243,23 @@ static int c_can_plat_probe(struct platform_device
*pdev)
return -ENODEV;
}
+pinctrl = devm_pinctrl_get(pdev-dev);
+if (!IS_ERR(pinctrl)) {
+struct pinctrl_state *s;
+
+/* Deactivate pins to prevent DRA7 DCAN IP from being
+ * stuck in transition when module is disabled.
+ * Pins are activated in c_can_start() and deactivated
+ * in c_can_stop()
+ */
+s = pinctrl_lookup_state(pinctrl, PINCTRL_STATE_SLEEP);
+if (!IS_ERR(s))
+pinctrl_select_state(pinctrl, s);
+} else {
+dev_warn(pdev-dev,
+ failed to get pinctrl\n);
+}
Can you move the initial setting into c_can.c, register_c_can_dev()
should be a good candidate.
OK. This should also address the NULL pointer issue you pointed out earlier
with c_can_pci.
cheers,
-roger
+
/* get the appropriate clk */
clk = devm_clk_get(pdev-dev, NULL);
if (IS_ERR(clk)) {
@@ -270,6 +289,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
}
priv = netdev_priv(dev);
+priv-pinctrl = pinctrl;
switch (drvdata-id) {
case BOSCH_C_CAN:
Marc
--
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 v4 4/8] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 11/13/2014 02:44 PM, Marc Kleine-Budde wrote:
On 11/07/2014 03:49 PM, Roger Quadros wrote:
Some TI SoCs like DRA7 have a RAMINIT register specification
different from the other AMxx SoCs and as expected by the
existing driver.
To add more insanity, this register is shared with other
IPs like DSS, PCIe and PWM.
Provides a more generic mechanism to specify the RAMINIT
register location and START/DONE bit position and use the
syscon/regmap framework to access the register.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/net/can/c_can.txt | 3 +
drivers/net/can/c_can/c_can.h | 11 +-
drivers/net/can/c_can/c_can_platform.c | 112
++---
3 files changed, 86 insertions(+), 40 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt
b/Documentation/devicetree/bindings/net/can/c_can.txt
index 8f1ae81..a3ca3ee 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -12,6 +12,9 @@ Required properties:
Optional properties:
- ti,hwmods : Must be d_cann or c_cann, n being the
instance number
+- syscon-raminit: Handle to system control region that contains the
+ RAMINIT register, register offset to the RAMINIT
+ register and the CAN instance number (0 offset).
Note: ti,hwmods field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 3c305a1..0e17c7b 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -179,6 +179,14 @@ struct c_can_driver_data {
bool raminit_pulse; /* If set, sets and clears START bit (pulse) */
};
+/* Out of band RAMINIT register access via syscon regmap */
+struct c_can_raminit {
+struct regmap *syscon; /* for raminit ctrl. reg. access */
+unsigned int reg; /* register index within syscon */
+u8 start_bit;
+u8 done_bit;
+};
+
/* c_can private data structure */
struct c_can_priv {
struct can_priv can;/* must be the first member */
@@ -196,8 +204,7 @@ struct c_can_priv {
const u16 *regs;
void *priv; /* for board-specific data */
enum c_can_dev_id type;
-u32 __iomem *raminit_ctrlreg;
-int instance;
+struct c_can_raminit raminit_sys; /* RAMINIT via syscon regmap */
void (*raminit) (const struct c_can_priv *priv, bool enable);
u32 comm_rcv_high;
u32 rxmasked;
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index 20deb67..3776483 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,14 +32,13 @@
#include linux/clk.h
#include linux/of.h
#include linux/of_device.h
+#include linux/mfd/syscon.h
+#include linux/regmap.h
#include linux/can/dev.h
#include c_can.h
-#define CAN_RAMINIT_START_MASK(i) (0x001 (i))
-#define CAN_RAMINIT_DONE_MASK(i)(0x100 (i))
-#define CAN_RAMINIT_ALL_MASK(i) (0x101 (i))
#define DCAN_RAM_INIT_BIT (1 3)
static DEFINE_SPINLOCK(raminit_lock);
/*
@@ -72,47 +71,61 @@ static void c_can_plat_write_reg_aligned_to_32bit(const
struct c_can_priv *priv,
writew(val, priv-base + 2 * priv-regs[index]);
}
-static void c_can_hw_raminit_wait_ti(const struct c_can_priv *priv, u32
mask,
- u32 val)
+static void c_can_hw_raminit_wait_syscon(const struct c_can_priv *priv,
+ u32 mask, u32 val)
{
int timeout = 0;
+const struct c_can_raminit *raminit = priv-raminit_sys;
+u32 ctrl;
+
/* We look only at the bits of our instance. */
val = mask;
-while ((readl(priv-raminit_ctrlreg) mask) != val) {
+do {
udelay(1);
timeout++;
+regmap_read(raminit-syscon, raminit-reg, ctrl);
if (timeout == 1000) {
dev_err(priv-dev-dev, %s: time out\n, __func__);
break;
}
-}
+} while ((ctrl mask) != val);
}
-static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
+static void c_can_hw_raminit_syscon(const struct c_can_priv *priv, bool
enable)
{
-u32 mask = CAN_RAMINIT_ALL_MASK(priv-instance);
+u32 mask;
u32 ctrl;
+const struct c_can_raminit *raminit = priv-raminit_sys;
+u8 start_bit, done_bit;
+
+start_bit = raminit-start_bit;
+done_bit = raminit-done_bit;
spin_lock(raminit_lock);
-ctrl = readl(priv-raminit_ctrlreg);
+mask = 1 start_bit | 1 done_bit;
+regmap_read(raminit-syscon, raminit-reg, ctrl);
+
/* We clear the done and start bit
[PATCH v8 6/7] ARM: EXYNOS: Add support for non-secure L2X0 resume
From: Tomasz Figa t.f...@samsung.com On Exynos SoCs it is necessary to resume operation of L2C early in assembly code, because otherwise certain systems will crash. This patch adds necessary code to non-secure resume handler. Signed-off-by: Tomasz Figa t.f...@samsung.com [rewrote the code accessing l2x0_saved_regs] Sigend-off-by: Marek Szyprowski m.szyprow...@samsung.com --- arch/arm/mach-exynos/sleep.S | 46 1 file changed, 46 insertions(+) diff --git a/arch/arm/mach-exynos/sleep.S b/arch/arm/mach-exynos/sleep.S index e3c373082bbe..31d25834b9c4 100644 --- a/arch/arm/mach-exynos/sleep.S +++ b/arch/arm/mach-exynos/sleep.S @@ -16,6 +16,8 @@ */ #include linux/linkage.h +#include asm/asm-offsets.h +#include asm/hardware/cache-l2x0.h #include smc.h #define CPU_MASK 0xff00 @@ -74,6 +76,45 @@ ENTRY(exynos_cpu_resume_ns) mov r0, #SMC_CMD_C15RESUME dsb smc #0 +#ifdef CONFIG_CACHE_L2X0 + adr r0, 1f + ldr r2, [r0] + add r0, r2, r0 + + /* Check that the address has been initialised. */ + ldr r1, [r0, #L2X0_R_PHY_BASE] + teq r1, #0 + beq skip_l2x0 + + /* Check if controller has been enabled. */ + ldr r2, [r1, #L2X0_CTRL] + tst r2, #0x1 + bne skip_l2x0 + + ldr r1, [r0, #L2X0_R_TAG_LATENCY] + ldr r2, [r0, #L2X0_R_DATA_LATENCY] + ldr r3, [r0, #L2X0_R_PREFETCH_CTRL] + mov r0, #SMC_CMD_L2X0SETUP1 + smc #0 + + /* Reload saved regs pointer because smc corrupts registers. */ + adr r0, 1f + ldr r2, [r0] + add r0, r2, r0 + + ldr r1, [r0, #L2X0_R_PWR_CTRL] + ldr r2, [r0, #L2X0_R_AUX_CTRL] + mov r0, #SMC_CMD_L2X0SETUP2 + smc #0 + + mov r0, #SMC_CMD_L2X0INVALL + smc #0 + + mov r1, #1 + mov r0, #SMC_CMD_L2X0CTRL + smc #0 +skip_l2x0: +#endif /* CONFIG_CACHE_L2X0 */ skip_cp15: b cpu_resume ENDPROC(exynos_cpu_resume_ns) @@ -83,3 +124,8 @@ cp15_save_diag: .globl cp15_save_power cp15_save_power: .long 0 @ cp15 power control + +#ifdef CONFIG_CACHE_L2X0 + .align +1: .long l2x0_saved_regs - . +#endif /* CONFIG_CACHE_L2X0 */ -- 1.9.2 -- 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 v8 1/7] ARM: l2c: Refactor the driver to use commit-like interface
From: Tomasz Figa t.f...@samsung.com
Certain implementations of secure hypervisors (namely the one found on
Samsung Exynos-based boards) do not provide access to individual L2C
registers. This makes the .write_sec()-based interface insufficient and
provoking ugly hacks.
This patch is first step to make the driver not rely on availability of
writes to individual registers. This is achieved by refactoring the
driver to use a commit-like operation scheme: all register values are
prepared first and stored in an instance of l2x0_regs struct and then a
single callback is responsible to flush those values to the hardware.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/mm/cache-l2x0.c | 210 ++-
1 file changed, 115 insertions(+), 95 deletions(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 5e65ca8dea62..e5948c5adaa7 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -41,12 +41,14 @@ struct l2c_init_data {
void (*enable)(void __iomem *, u32, unsigned);
void (*fixup)(void __iomem *, u32, struct outer_cache_fns *);
void (*save)(void __iomem *);
+ void (*configure)(void __iomem *);
struct outer_cache_fns outer_cache;
};
#define CACHE_LINE_SIZE32
static void __iomem *l2x0_base;
+static const struct l2c_init_data *l2x0_data;
static DEFINE_RAW_SPINLOCK(l2x0_lock);
static u32 l2x0_way_mask; /* Bitmask of active ways */
static u32 l2x0_size;
@@ -106,6 +108,14 @@ static inline void l2c_unlock(void __iomem *base, unsigned
num)
}
}
+static void l2c_configure(void __iomem *base)
+{
+ if (l2x0_data-configure)
+ l2x0_data-configure(base);
+
+ l2c_write_sec(l2x0_saved_regs.aux_ctrl, base, L2X0_AUX_CTRL);
+}
+
/*
* Enable the L2 cache controller. This function must only be
* called when the cache controller is known to be disabled.
@@ -114,7 +124,12 @@ static void l2c_enable(void __iomem *base, u32 aux,
unsigned num_lock)
{
unsigned long flags;
- l2c_write_sec(aux, base, L2X0_AUX_CTRL);
+ /* Do not touch the controller if already enabled. */
+ if (readl_relaxed(base + L2X0_CTRL) L2X0_CTRL_EN)
+ return;
+
+ l2x0_saved_regs.aux_ctrl = aux;
+ l2c_configure(base);
l2c_unlock(base, num_lock);
@@ -208,6 +223,11 @@ static void l2c_save(void __iomem *base)
l2x0_saved_regs.aux_ctrl = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
}
+static void l2c_resume(void)
+{
+ l2c_enable(l2x0_base, l2x0_saved_regs.aux_ctrl, l2x0_data-num_lock);
+}
+
/*
* L2C-210 specific code.
*
@@ -288,14 +308,6 @@ static void l2c210_sync(void)
__l2c210_cache_sync(l2x0_base);
}
-static void l2c210_resume(void)
-{
- void __iomem *base = l2x0_base;
-
- if (!(readl_relaxed(base + L2X0_CTRL) L2X0_CTRL_EN))
- l2c_enable(base, l2x0_saved_regs.aux_ctrl, 1);
-}
-
static const struct l2c_init_data l2c210_data __initconst = {
.type = L2C-210,
.way_size_0 = SZ_8K,
@@ -309,7 +321,7 @@ static const struct l2c_init_data l2c210_data __initconst =
{
.flush_all = l2c210_flush_all,
.disable = l2c_disable,
.sync = l2c210_sync,
- .resume = l2c210_resume,
+ .resume = l2c_resume,
},
};
@@ -466,7 +478,7 @@ static const struct l2c_init_data l2c220_data = {
.flush_all = l2c220_flush_all,
.disable = l2c_disable,
.sync = l2c220_sync,
- .resume = l2c210_resume,
+ .resume = l2c_resume,
},
};
@@ -615,39 +627,29 @@ static void __init l2c310_save(void __iomem *base)
L310_POWER_CTRL);
}
-static void l2c310_resume(void)
+static void l2c310_configure(void __iomem *base)
{
- void __iomem *base = l2x0_base;
+ unsigned revision;
- if (!(readl_relaxed(base + L2X0_CTRL) L2X0_CTRL_EN)) {
- unsigned revision;
-
- /* restore pl310 setup */
- writel_relaxed(l2x0_saved_regs.tag_latency,
- base + L310_TAG_LATENCY_CTRL);
- writel_relaxed(l2x0_saved_regs.data_latency,
- base + L310_DATA_LATENCY_CTRL);
- writel_relaxed(l2x0_saved_regs.filter_end,
- base + L310_ADDR_FILTER_END);
- writel_relaxed(l2x0_saved_regs.filter_start,
- base + L310_ADDR_FILTER_START);
-
- revision = readl_relaxed(base + L2X0_CACHE_ID)
- L2X0_CACHE_ID_RTL_MASK;
-
- if (revision = L310_CACHE_ID_RTL_R2P0)
- l2c_write_sec(l2x0_saved_regs.prefetch_ctrl, base,
-
[PATCH v8 7/7] ARM: dts: exynos4: Add nodes for L2 cache controller
From: Tomasz Figa t.f...@samsung.com
This patch adds device tree nodes for L2 cache controller present on
Exynos4 SoCs.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
2 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index bcc9e63c8070..8e45ea44317e 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -81,6 +81,15 @@
reg = 0x10023CA0 0x20;
};
+ l2c: l2-cache-controller@10502000 {
+ compatible = arm,pl310-cache;
+ reg = 0x10502000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ arm,tag-latency = 2 2 1;
+ arm,data-latency = 2 2 1;
+ };
+
gic: interrupt-controller@1049 {
cpu-offset = 0x8000;
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 861bb919f6d3..c7adfd60ad3a 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -54,6 +54,20 @@
reg = 0x10023CA0 0x20;
};
+ l2c: l2-cache-controller@10502000 {
+ compatible = arm,pl310-cache;
+ reg = 0x10502000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ arm,tag-latency = 2 2 1;
+ arm,data-latency = 3 2 1;
+ arm,double-linefill = 1;
+ arm,double-linefill-incr = 0;
+ arm,double-linefill-wrap = 1;
+ arm,prefetch-drop = 1;
+ arm,prefetch-offset = 7;
+ };
+
clock: clock-controller@1003 {
compatible = samsung,exynos4412-clock;
reg = 0x1003 0x2;
--
1.9.2
--
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 v8 3/7] ARM: l2c: Get outer cache .write_sec callback from mach_desc only if not NULL
From: Tomasz Figa t.f...@samsung.com
Certain platforms (i.e. Exynos) might need to set .write_sec callback
from firmware initialization which is happenning in .init_early callback
of machine descriptor. However current code will overwrite the pointer
with whatever is present in machine descriptor, even though it can be
already set earlier. This patch fixes this by making the assignment
conditional, depending on whether current .write_sec callback is NULL.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/kernel/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 7c81ec428b9b..5acb8aef6f2d 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -108,7 +108,8 @@ void __init init_IRQ(void)
if (IS_ENABLED(CONFIG_OF) IS_ENABLED(CONFIG_CACHE_L2X0)
(machine_desc-l2c_aux_mask || machine_desc-l2c_aux_val)) {
- outer_cache.write_sec = machine_desc-l2c_write_sec;
+ if (!outer_cache.write_sec)
+ outer_cache.write_sec = machine_desc-l2c_write_sec;
ret = l2x0_of_init(machine_desc-l2c_aux_val,
machine_desc-l2c_aux_mask);
if (ret)
--
1.9.2
--
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 v8 2/7] ARM: l2c: Add interface to ask hypervisor to configure L2C
From: Tomasz Figa t.f...@samsung.com
Because certain secure hypervisor do not allow writes to individual L2C
registers, but rather expect set of parameters to be passed as argument
to secure monitor calls, there is a need to provide an interface for the
L2C driver to ask the firmware to configure the hardware according to
specified parameters. This patch adds such.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/include/asm/outercache.h | 3 +++
arch/arm/mm/cache-l2x0.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/arch/arm/include/asm/outercache.h
b/arch/arm/include/asm/outercache.h
index 891a56b35bcf..563b92fc2f41 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -23,6 +23,8 @@
#include linux/types.h
+struct l2x0_regs;
+
struct outer_cache_fns {
void (*inv_range)(unsigned long, unsigned long);
void (*clean_range)(unsigned long, unsigned long);
@@ -36,6 +38,7 @@ struct outer_cache_fns {
/* This is an ARM L2C thing */
void (*write_sec)(unsigned long, unsigned);
+ void (*configure)(const struct l2x0_regs *);
};
extern struct outer_cache_fns outer_cache;
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index e5948c5adaa7..d214be207517 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -110,6 +110,11 @@ static inline void l2c_unlock(void __iomem *base, unsigned
num)
static void l2c_configure(void __iomem *base)
{
+ if (outer_cache.configure) {
+ outer_cache.configure(l2x0_saved_regs);
+ return;
+ }
+
if (l2x0_data-configure)
l2x0_data-configure(base);
@@ -910,6 +915,7 @@ static int __init __l2c_init(const struct l2c_init_data
*data,
fns = data-outer_cache;
fns.write_sec = outer_cache.write_sec;
+ fns.configure = outer_cache.configure;
if (data-fixup)
data-fixup(l2x0_base, cache_id, fns);
--
1.9.2
--
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 v8 5/7] ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
From: Tomasz Figa t.f...@samsung.com
Exynos4 SoCs equipped with an L2C-310 cache controller and running under
secure firmware require certain registers of aforementioned IP to be
accessed only from secure mode. This means that SMC calls are required
for certain register writes. To handle this, an implementation of
.write_sec and .configure callbacks is provided by this patch.
Signed-off-by: Tomasz Figa t.f...@samsung.com
[added comment and reworked unconditional call to SMC_CMD_L2X0INVALL]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/mach-exynos/firmware.c | 50 +
1 file changed, 50 insertions(+)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 766f57d2f029..dc5ae53aa317 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -17,6 +17,7 @@
#include asm/cacheflush.h
#include asm/cputype.h
#include asm/firmware.h
+#include asm/hardware/cache-l2x0.h
#include asm/suspend.h
#include mach/map.h
@@ -136,6 +137,43 @@ static const struct firmware_ops exynos_firmware_ops = {
.resume = IS_ENABLED(CONFIG_EXYNOS_CPU_SUSPEND) ?
exynos_resume : NULL,
};
+static void exynos_l2_write_sec(unsigned long val, unsigned reg)
+{
+ static int l2cache_enabled;
+
+ switch (reg) {
+ case L2X0_CTRL:
+ if (val L2X0_CTRL_EN) {
+ /*
+* Before the cache can be enabled, due to firmware
+* design, SMC_CMD_L2X0INVALL must be called.
+*/
+ if (!l2cache_enabled) {
+ exynos_smc(SMC_CMD_L2X0INVALL, 0, 0, 0);
+ l2cache_enabled = 1;
+ }
+ } else {
+ l2cache_enabled = 0;
+ }
+ exynos_smc(SMC_CMD_L2X0CTRL, val, 0, 0);
+ break;
+
+ case L2X0_DEBUG_CTRL:
+ exynos_smc(SMC_CMD_L2X0DEBUG, val, 0, 0);
+ break;
+
+ default:
+ WARN_ONCE(1, %s: ignoring write to reg 0x%x\n, __func__, reg);
+ }
+}
+
+static void exynos_l2_configure(const struct l2x0_regs *regs)
+{
+ exynos_smc(SMC_CMD_L2X0SETUP1, regs-tag_latency, regs-data_latency,
+ regs-prefetch_ctrl);
+ exynos_smc(SMC_CMD_L2X0SETUP2, regs-pwr_ctrl, regs-aux_ctrl, 0);
+}
+
void __init exynos_firmware_init(void)
{
struct device_node *nd;
@@ -155,4 +193,16 @@ void __init exynos_firmware_init(void)
pr_info(Running under secure firmware.\n);
register_firmware_ops(exynos_firmware_ops);
+
+ /*
+* Exynos 4 SoCs (based on Cortex A9 and equipped with L2C-310),
+* running under secure firmware, require certain registers of L2
+* cache controller to be written in secure mode. Here .write_sec
+* callback is provided to perform necessary SMC calls.
+*/
+ if (IS_ENABLED(CONFIG_CACHE_L2X0)
+read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
+ outer_cache.write_sec = exynos_l2_write_sec;
+ outer_cache.configure = exynos_l2_configure;
+ }
}
--
1.9.2
--
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 v8 4/7] ARM: l2c: Add support for overriding prefetch settings
From: Tomasz Figa t.f...@samsung.com
Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch
settings configured in registers leading to crashes if L2C is enabled
without overriding them. This patch introduces bindings to enable
prefetch settings to be specified from DT and necessary support in the
driver.
Signed-off-by: Tomasz Figa t.f...@samsung.com
[mszyprow: rebased onto v3.18-rc1, added error message when prefetch related
dt property has been provided without any value]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
Documentation/devicetree/bindings/arm/l2cc.txt | 10 +
arch/arm/mm/cache-l2x0.c | 54 ++
2 files changed, 64 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt
b/Documentation/devicetree/bindings/arm/l2cc.txt
index 292ef7ca3058..0dbabe9a6b0a 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -57,6 +57,16 @@ Optional properties:
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
+- arm,double-linefill : Override double linefill enable setting. Enable if
+ non-zero, disable if zero.
+- arm,double-linefill-incr : Override double linefill on INCR read. Enable
+ if non-zero, disable if zero.
+- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
+ if non-zero, disable if zero.
+- arm,prefetch-drop : Override prefetch drop enable setting. Enable if
non-zero,
+ disable if zero.
+- arm,prefetch-offset : Override prefetch offset value. Valid values are
+ 0-7, 15, 23, and 31.
Example:
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index d214be207517..6f9d5a02d053 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1169,6 +1169,8 @@ static void __init l2c310_of_parse(const struct
device_node *np,
u32 tag[3] = { 0, 0, 0 };
u32 filter[2] = { 0, 0 };
u32 assoc;
+ u32 prefetch;
+ u32 val;
int ret;
of_property_read_u32_array(np, arm,tag-latency, tag, ARRAY_SIZE(tag));
@@ -1214,6 +1216,58 @@ static void __init l2c310_of_parse(const struct
device_node *np,
assoc);
break;
}
+
+ prefetch = l2x0_saved_regs.prefetch_ctrl;
+
+ ret = of_property_read_u32(np, arm,double-linefill, val);
+ if (ret == 0) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,double-linefill property value is
missing\n);
+ }
+
+ ret = of_property_read_u32(np, arm,double-linefill-incr, val);
+ if (ret == 0) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL_INCR;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL_INCR;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,double-linefill-incr property value is
missing\n);
+ }
+
+ ret = of_property_read_u32(np, arm,double-linefill-wrap, val);
+ if (ret == 0) {
+ if (!val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL_WRAP;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL_WRAP;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,double-linefill-wrap property value is
missing\n);
+ }
+
+ ret = of_property_read_u32(np, arm,prefetch-drop, val);
+ if (ret == 0) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_PREFETCH_DROP;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_PREFETCH_DROP;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,prefetch-drop property value is
missing\n);
+ }
+
+ ret = of_property_read_u32(np, arm,prefetch-offset, val);
+ if (ret == 0) {
+ prefetch = ~L310_PREFETCH_CTRL_OFFSET_MASK;
+ prefetch |= val L310_PREFETCH_CTRL_OFFSET_MASK;
+ } else if (ret != -EINVAL) {
+ pr_err(L2C-310 OF arm,prefetch-offset property value is
missing\n);
+ }
+
+ l2x0_saved_regs.prefetch_ctrl = prefetch;
}
static const struct l2c_init_data of_l2c310_data __initconst = {
--
1.9.2
--
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 v8 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
This is an updated patchset, which intends to add support for L2 cache
on Exynos4 SoCs on boards running under secure firmware, which requires
certain initialization steps to be done with help of firmware, as
selected registers are writable only from secure mode.
First four patches extend existing support for secure write in L2C driver
to account for design of secure firmware running on Exynos. Namely:
1) direct read access to certain registers is needed on Exynos, because
secure firmware calls set several registers at once,
2) not all boards are running secure firmware, so .write_sec callback
needs to be installed in Exynos firmware ops initialization code,
3) write access to {DATA,TAG}_LATENCY_CTRL registers fron non-secure world
is not allowed and so must use l2c_write_sec as well,
4) on certain boards, default value of prefetch register is incorrect
and must be overridden at L2C initialization.
For boards running with firmware that provides access to individual
L2C registers this series should introduce no functional changes. However
since the driver is widely used on other platforms I'd like to kindly ask
any interested people for testing.
Further three patches add implementation of .write_sec and .configure
callbacks for Exynos secure firmware and necessary DT nodes to enable
L2 cache.
Changes in this version tested on Exynos4412-based TRATS2 and OdroidU3+
boards (both with secure firmware). There should be no functional change
for Exynos boards running without secure firmware. I do not have access
to affected non-Exynos boards, so I could not test on them.
Depends on:
- [PATCH v3 0/5] Firmware-assisted suspend/resume of Exynos SoCs
(https://lkml.org/lkml/2014/8/26/445)
available in samsung/pm2 branch in
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
- L2C patches merged to v3.18-rc3
Changelog:
Changes since v7:
(https://lkml.org/lkml/2014/10/29/158)
- rebased onto arm-soc/for-next kernel tree (depends on patches merged to
v3.18-rc3 and arm-soc/samsung/pm2 branch)
- removed 'ARM: l2c: unify L2C-310 OF initialization error messages' patch
(no longer needed)
Changes since v6:
(https://lkml.org/lkml/2014/10/27/233)
- changed PL310 to L2C-310 prefix in error messages
- added patch shortening the error message about incorrect associativity
Changes since v5:
(https://lkml.org/lkml/2014/9/24/364)
- rebased onto v3.18-rc2
- added error message about missing properties values
Changes since v4:
(https://lkml.org/lkml/2014/8/26/461)
- rewrote the code accessing l2x0_saved_regs from assembly code
- added comment and reworked unconditional call to SMC_CMD_L2X0INVALL
Patch summary:
Tomasz Figa (7):
ARM: l2c: Refactor the driver to use commit-like interface
ARM: l2c: Add interface to ask hypervisor to configure L2C
ARM: l2c: Get outer cache .write_sec callback from mach_desc only if
not NULL
ARM: l2c: Add support for overriding prefetch settings
ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
ARM: EXYNOS: Add support for non-secure L2X0 resume
ARM: dts: exynos4: Add nodes for L2 cache controller
Documentation/devicetree/bindings/arm/l2cc.txt | 10 +
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
arch/arm/include/asm/outercache.h | 3 +
arch/arm/kernel/irq.c | 3 +-
arch/arm/mach-exynos/firmware.c| 50 +
arch/arm/mach-exynos/sleep.S | 46 +
arch/arm/mm/cache-l2x0.c | 270 -
8 files changed, 309 insertions(+), 96 deletions(-)
--
1.9.2
--
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 v4 06/10] ARM: dts: am4372: Add DCAN nodes
On 11/13/2014 01:22 PM, Roger Quadros wrote:
The SoC contains 2 DCAN modules. Add them.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 899c57c..12fb1db 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -901,6 +901,28 @@
compatible = mmio-sram;
reg = 0x4030 0x4; /* 256k */
};
+
+ dcan0: can@481cc000 {
+ compatible = ti,am3352-d_can;
You should add ti,am4372-d_can as first compatible here.
+ ti,hwmods = d_can0;
+ clocks = dcan0_fck;
+ clock-names = fck;
+ reg = 0x481cc000 0x2000;
+ syscon-raminit = am43xx_control_module 0x644 0;
+ interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
+ dcan1: can@481d {
+ compatible = ti,am3352-d_can;
Same here.
+ ti,hwmods = d_can1;
+ clocks = dcan1_fck;
+ clock-names = fck;
+ reg = 0x481d 0x2000;
+ syscon-raminit = am43xx_control_module 0x644 1;
+ interrupts = GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
};
};
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 06/10] ARM: dts: am4372: Add DCAN nodes
On 11/13/2014 04:07 PM, Marc Kleine-Budde wrote:
On 11/13/2014 01:22 PM, Roger Quadros wrote:
The SoC contains 2 DCAN modules. Add them.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 899c57c..12fb1db 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -901,6 +901,28 @@
compatible = mmio-sram;
reg = 0x4030 0x4; /* 256k */
};
+
+dcan0: can@481cc000 {
+compatible = ti,am3352-d_can;
You should add ti,am4372-d_can as first compatible here.
We don't have a separate compatible id for am4372-d_can
as it the IP exactly same as am3352-d_can.
cheers,
-roger
+ti,hwmods = d_can0;
+clocks = dcan0_fck;
+clock-names = fck;
+reg = 0x481cc000 0x2000;
+syscon-raminit = am43xx_control_module 0x644 0;
+interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH;
+status = disabled;
+};
+
+dcan1: can@481d {
+compatible = ti,am3352-d_can;
Same here.
+ti,hwmods = d_can1;
+clocks = dcan1_fck;
+clock-names = fck;
+reg = 0x481d 0x2000;
+syscon-raminit = am43xx_control_module 0x644 1;
+interrupts = GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH;
+status = disabled;
+};
};
};
Marc
--
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 v4 06/10] ARM: dts: am4372: Add DCAN nodes
On 11/13/2014 03:40 PM, Roger Quadros wrote:
On 11/13/2014 04:07 PM, Marc Kleine-Budde wrote:
On 11/13/2014 01:22 PM, Roger Quadros wrote:
The SoC contains 2 DCAN modules. Add them.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 899c57c..12fb1db 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -901,6 +901,28 @@
compatible = mmio-sram;
reg = 0x4030 0x4; /* 256k */
};
+
+ dcan0: can@481cc000 {
+ compatible = ti,am3352-d_can;
You should add ti,am4372-d_can as first compatible here.
We don't have a separate compatible id for am4372-d_can
as it the IP exactly same as am3352-d_can.
Having the ti,am4372-d_can compatible gives you the freedom to add
some spacial handling for the IP if there turns that you need to without
needing to modify the device tree. (We do this on imx.)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 06/10] ARM: dts: am4372: Add DCAN nodes
On 11/13/2014 04:44 PM, Marc Kleine-Budde wrote:
On 11/13/2014 03:40 PM, Roger Quadros wrote:
On 11/13/2014 04:07 PM, Marc Kleine-Budde wrote:
On 11/13/2014 01:22 PM, Roger Quadros wrote:
The SoC contains 2 DCAN modules. Add them.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 899c57c..12fb1db 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -901,6 +901,28 @@
compatible = mmio-sram;
reg = 0x4030 0x4; /* 256k */
};
+
+ dcan0: can@481cc000 {
+ compatible = ti,am3352-d_can;
You should add ti,am4372-d_can as first compatible here.
We don't have a separate compatible id for am4372-d_can
as it the IP exactly same as am3352-d_can.
Having the ti,am4372-d_can compatible gives you the freedom to add
some spacial handling for the IP if there turns that you need to without
needing to modify the device tree. (We do this on imx.)
Agreed. On OMAP platforms we don't add new compatible IDs unless we really need
to.
Can we add ti,am4372-d_can even if it is not mentioned in
Documentation/devicetree/bindings?
Tony what is your preference?
cheers,
-roger
--
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 v4 06/10] ARM: dts: am4372: Add DCAN nodes
On 11/13/2014 03:49 PM, Roger Quadros wrote:
On 11/13/2014 04:44 PM, Marc Kleine-Budde wrote:
On 11/13/2014 03:40 PM, Roger Quadros wrote:
On 11/13/2014 04:07 PM, Marc Kleine-Budde wrote:
On 11/13/2014 01:22 PM, Roger Quadros wrote:
The SoC contains 2 DCAN modules. Add them.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 899c57c..12fb1db 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -901,6 +901,28 @@
compatible = mmio-sram;
reg = 0x4030 0x4; /* 256k */
};
+
+ dcan0: can@481cc000 {
+ compatible = ti,am3352-d_can;
You should add ti,am4372-d_can as first compatible here.
We don't have a separate compatible id for am4372-d_can
as it the IP exactly same as am3352-d_can.
Having the ti,am4372-d_can compatible gives you the freedom to add
some spacial handling for the IP if there turns that you need to without
needing to modify the device tree. (We do this on imx.)
Agreed. On OMAP platforms we don't add new compatible IDs unless we really
need to.
Can we add ti,am4372-d_can even if it is not mentioned in
Documentation/devicetree/bindings?
Tony what is your preference?
I don't insist, do it the Omap way :)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
[RFC PATCH 1/3] mmc: omap_hsmmc: set host capabilities by reading MMCHS_CAPA2 register
From: Viswanath Puttagunta vi...@ti.com
set SDR104, SDR50, DDR50 and HS200 capability flags to caps/caps2 by reading
MMCHS_CAPA2 register.
Signed-off-by: Viswanath Puttagunta vi...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Suggested-by: Misael Lopez Cruz misael.lo...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index df27bb4..2e42ed3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -64,6 +64,7 @@
#define OMAP_HSMMC_ISE 0x0138
#define OMAP_HSMMC_AC120x013C
#define OMAP_HSMMC_CAPA0x0140
+#define OMAP_HSMMC_CAPA2 0x0144
#define VS18 (1 26)
#define VS30 (1 25)
@@ -139,6 +140,10 @@
#define ACTO (1 1)
#define ACNE (1 0)
+#define SDR50 (1 0)
+#define SDR104 (1 1)
+#define DDR50 (1 2)
+
#define MMC_AUTOSUSPEND_DELAY 100
#define MMC_TIMEOUT_MS 20 /* 20 mSec */
#define MMC_TIMEOUT_US 2 /* 2 micro Sec */
@@ -2028,6 +2033,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
unsigned tx_req, rx_req;
const struct omap_mmc_of_data *data;
void __iomem *base;
+ u32 reg;
match = of_match_device(of_match_ptr(omap_mmc_of_match), pdev-dev);
if (match) {
@@ -2153,6 +2159,19 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
mmc-pm_caps = mmc_slot(host).pm_caps;
+ reg = OMAP_HSMMC_READ(host-base, OMAP_HSMMC_CAPA2);
+
+ if (reg SDR50)
+ mmc-caps |= MMC_CAP_UHS_DDR50;
+
+ if (reg SDR104) {
+ mmc-caps |= MMC_CAP_UHS_SDR104;
+ mmc-caps2 |= MMC_CAP2_HS200;
+ }
+
+ if (reg DDR50)
+ mmc-caps |= MMC_CAP_UHS_DDR50;
+
omap_hsmmc_conf_bus_power(host);
if (!pdev-dev.of_node) {
--
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
[RFC PATCH 3/3] ARM: dts: dra72-evm: Set the max-frequency to 192MHz
Set the maximum operating frequency of MMC2 to 192MHz.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/dra72-evm.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index abbaaa7..5cc1110 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -364,6 +364,7 @@
vmmc-supply = evm_3v3;
bus-width = 8;
ti,non-removable;
+ max-frequency = 19200;
};
dra7_pmx_core {
--
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
Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 11/13/2014 12:00 PM, Tomi Valkeinen wrote: Hi, On 13/11/14 11:17, Jean-Francois Moine wrote: On Thu, 13 Nov 2014 10:05:28 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: ... and I saw only a few dependencies between the 2 subsystems: - the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -), The video mode (i.e. availability of audio) or the EDID (i.e. the supported audio parameters) may change at any time, so I presume in your series the video side will inform the codec of these changes at any point? - the CODEC must alert the transmitter on audio start and stop. I don't think that stopping audio streaming on HDMI disconnection is And you allow audio playback also if the monitor does not support audio, or the video mode does not supprot audio? useful. I even let audio streaming start when the HDMI cable is disconnected. Ah, this is actually unclear thing to me: what should the audio side behavior be when the HDMI cable is disconnected or the video is blanked? I believe the options are: a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere? b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave? c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work. Jyri, were there some other options we discussed? There was the 4th option: the driver forcing pause on the pcm when the cable is disconnected or screen is blanked and resuming it automatically when the picture is back. But I think that is maybe too hackish solution. Considering the big picture, including the userspace. I think we would need some way to tell the userspace when the HDMI device is available. The problem is the same for both a and c cases. Maybe a read only alsa mixer could be used for that. Cheers, Jyri Currently, the OMAP HDMI version does c). It's the easiest solution for us. Option a) is a bit problematic for us, as it requires the HDMI IP side to be fully operational, with the video output configured and enabled, as that is what drives the audio DMA. If we stop the video, I believe the audio DMA will freeze, and it'll lead to timeouts on the audio side. I haven't tried, but I believe we could program the HDMI IP to some safe default video mode if the cable is disconnected, and turn off the actual HDMI PHY, so that the audio side could work even if the HDMI stream is not going anywhere. I think it would be quite big change to how the HDMI driver works at the moment. But then, if the cable _is_ connected and the video mode is such that it cannot not support audio, I wonder if we can still fake the audio playback or will the HDMI IP get confused... -- 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
[RFC PATCH 2/3] mmc: omap_hsmmc: add tuning support
From: Balaji T K balaj...@ti.com
MMC tuning procedure is required to support SD card
UHS1-SDR104 mode and EMMC HS200 mode.
The tuning function omap_execute_tuning() will only
be called by the MMC/SD core if the corresponding
speed modes are supported by the OMAP silicon which
is set in the mmc host caps field.
Signed-off-by: Viswanath Puttagunta vi...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
[ kis...@ti.com : Set the functional clock to 192MHz if the contoller
supports HS200 ]
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 325 -
1 file changed, 322 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2e42ed3..675bd31d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -22,6 +22,7 @@
#include linux/dmaengine.h
#include linux/seq_file.h
#include linux/sizes.h
+#include linux/slab.h
#include linux/interrupt.h
#include linux/delay.h
#include linux/dma-mapping.h
@@ -47,6 +48,7 @@
/* OMAP HSMMC Host Controller Registers */
#define OMAP_HSMMC_SYSSTATUS 0x0014
#define OMAP_HSMMC_CON 0x002C
+#define OMAP_HSMMC_DLL 0x0034
#define OMAP_HSMMC_SDMASA 0x0100
#define OMAP_HSMMC_BLK 0x0104
#define OMAP_HSMMC_ARG 0x0108
@@ -100,6 +102,7 @@
#define CLKEXTFREE (1 16)
#define CTPL (1 11)
#define DW8(1 5)
+#define BRR(1 5)
#define OD 0x1
#define STAT_CLEAR 0x
#define INIT_STREAM_CMD0x
@@ -129,6 +132,20 @@
#define CERR_EN(1 28)
#define BADA_EN(1 29)
+#define V1V8_SIGEN (1 19)
+#define AC12_SCLK_SEL (1 23)
+#define AC12_UHSMC_MASK(7 16)
+#define AC12_UHSMC_SDR50 (2 16)
+#define AC12_UHSMC_SDR104 (3 16)
+#define DLL_LOCK (1 0)
+#define DLL_CALIB (1 1)
+#define DLL_UNLOCK_STICKY (1 2)
+#define DLL_SWT(1 20)
+#define DLL_FORCE_SR_C_MASK(0x7F 13)
+#define DLL_FORCE_SR_C_SHIFT 13
+#define DLL_FORCE_VALUE(1 12)
+#define DLL_RESET (1 31)
+
#define INT_EN_MASK (BADA_EN | CERR_EN | ACE_EN | DEB_EN | DCRC_EN |\
DTO_EN | CIE_EN | CEB_EN | CCRC_EN | CTO_EN | \
BRR_EN | BWR_EN | TC_EN | CC_EN)
@@ -143,18 +160,23 @@
#define SDR50 (1 0)
#define SDR104 (1 1)
#define DDR50 (1 2)
+#define CAPA2_TSDR50 (1 13)
#define MMC_AUTOSUSPEND_DELAY 100
#define MMC_TIMEOUT_MS 20 /* 20 mSec */
#define MMC_TIMEOUT_US 2 /* 2 micro Sec */
#define OMAP_MMC_MIN_CLOCK 40
#define OMAP_MMC_MAX_CLOCK 5200
+#define MAX_PHASE_DELAY0x7F
#define DRIVER_NAMEomap_hsmmc
#define VDD_1V8180 /* 18 uV */
#define VDD_3V0300 /* 30 uV */
#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
+#define EMMC_HSDDR_SD_SDR25_MAX5200
+#define SD_SDR50_MAX_FREQ 10400
+
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -198,6 +220,7 @@ struct omap_hsmmc_host {
void__iomem *base;
resource_size_t mapbase;
spinlock_t irq_lock; /* Prevent races with irq handler */
+ struct completion buf_ready;
unsigned intdma_len;
unsigned intdma_sg_idx;
unsigned char bus_mode;
@@ -224,6 +247,13 @@ struct omap_hsmmc_host {
#define AUTO_CMD23 (1 0)/* Auto CMD23 support */
#define HSMMC_SDIO_IRQ_ENABLED (1 1)/* SDIO irq enabled */
#define HSMMC_WAKE_IRQ_ENABLED (1 2)
+
+ u32 *tuning_data;
+ int tuning_size;
+ int tuning_done;
+ int tuning_fsrc;
+ u32 tuning_uhsmc;
+ u32 tuning_opcode;
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -233,6 +263,48 @@ struct omap_mmc_of_data {
u8 controller_flags;
};
+static const u32 ref_tuning_4bits[] = {
+ 0x00FF0FFF, 0xCCC3CCFF, 0xFFCC3CC3, 0xEFFEFFFE,
+ 0xDDFFDFFF, 0xFBFFFBFF, 0xFF7FFFBF, 0xEFBDF777,
+ 0xF0FFF0FF, 0x3CCCFC0F, 0xCFCC33CC, 0xEEFFEFFF,
+ 0xFDFFFDFF, 0xFFBFFFDF, 0xFFF7FFBB, 0xDE7B7FF7
+};
+
+static const u32 ref_tuning_8bits[] = {
+ 0xFF00, 0x, 0x, 0x33CC,
+ 0xCCCC, 0x, 0xEEFF, 0xFFFF,
+ 0xFFDD, 0x, 0xBBFF, 0xBBFF,
+
Re: [RFC PATCH 0/3] DRA72: MMC HS200 support
Hi, Sorry for sending this multiple times. There was some problem with my mail configuration which I have fixed now. Thanks Kishon On Thursday 13 November 2014 08:24 PM, Kishon Vijay Abraham I wrote: Added HS200 to improve EMMC throughput for dra72. With HS200 == Read throughput ./dd if=/dev/mmcblk0 of=/dev/null bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 1.46028 s, 71.8 MB/s Write throughput root@dra7xx-evm:/# ./dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 9.34884 s, 11.2 MB/s WithOUT HS200 == Read throughput ./dd if=/dev/mmcblk0 of=/dev/null bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 2.6423 s, 39.7 MB/s Write throughput ./dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 9.3556 s, 11.2 MB/s Balaji T K (1): mmc: omap_hsmmc: add tuning support Kishon Vijay Abraham I (1): ARM: dts: dra72-evm: Set the max-frequency to 192MHz Viswanath Puttagunta (1): mmc: omap_hsmmc: set host capabilities by reading MMCHS_CAPA2 register arch/arm/boot/dts/dra72-evm.dts |1 + drivers/mmc/host/omap_hsmmc.c | 342 ++- 2 files changed, 341 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
[RFC PATCH 0/3] DRA72: MMC HS200 support
Added HS200 to improve EMMC throughput for dra72. With HS200 == Read throughput ./dd if=/dev/mmcblk0 of=/dev/null bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 1.46028 s, 71.8 MB/s Write throughput root@dra7xx-evm:/# ./dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 9.34884 s, 11.2 MB/s WithOUT HS200 == Read throughput ./dd if=/dev/mmcblk0 of=/dev/null bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 2.6423 s, 39.7 MB/s Write throughput ./dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=100 oflag=sync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 9.3556 s, 11.2 MB/s Balaji T K (1): mmc: omap_hsmmc: add tuning support Kishon Vijay Abraham I (1): ARM: dts: dra72-evm: Set the max-frequency to 192MHz Viswanath Puttagunta (1): mmc: omap_hsmmc: set host capabilities by reading MMCHS_CAPA2 register arch/arm/boot/dts/dra72-evm.dts |1 + drivers/mmc/host/omap_hsmmc.c | 342 ++- 2 files changed, 341 insertions(+), 2 deletions(-) -- 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
Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On Thu, 13 Nov 2014 12:00:41 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: [snip] Jyri or Peter knows this better, but I think one difference with OMAP HDMI case and tda998x is that tda998x is an external encoder, and you transfer audio data to it via i2s or spdif, whereas OMAP HDMI is inside the SoC, and the HDMI IP gets the audio data via system DMA. The system DMA transfers are triggered by the HDMI IP, and the HDMI IP has to be enabled and properly configured for the DMA ports to function. So, correct me if I'm wrong, but I think this is the fundamental difference: In your case, the actual audio playback happens with the i2s or spdif side. You can enable the playback at any time, no matter what is the status of tda998x. If tda998x is not operational, the audio data will just go to /dev/null. In our case, the actual audio playback happens inside the HDMI block. We need the whole HDMI block to be operational and correctly configured for (fake or real) playback to be possible. When the tda998x is not operational, the CODEC knows it and reports an error to the audio subsystem on device open. But, once the tda998x has been started, it always stays operational, even without HDMI connection. and I saw only a few dependencies between the 2 subsystems: - the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -), The video mode (i.e. availability of audio) or the EDID (i.e. the supported audio parameters) may change at any time, so I presume in your series the video side will inform the codec of these changes at any point? Such changes occur only when the HDMI output device (TV) is replaced by an other one (manual cable exchange or HDMI switcher). I wonder if these changes are correctly treated in the HDMI transmitters, DRM core, DRM drivers, X11/wayland... So, no, actually, once streaming is started, no information go from the HDMI transmitter to the CODEC. - the CODEC must alert the transmitter on audio start and stop. I don't think that stopping audio streaming on HDMI disconnection is And you allow audio playback also if the monitor does not support audio, or the video mode does not supprot audio? Bug in my patch: audio playback will be rejected if there will be no audio support. useful. I even let audio streaming start when the HDMI cable is disconnected. Ah, this is actually unclear thing to me: what should the audio side behavior be when the HDMI cable is disconnected or the video is blanked? I believe the options are: a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere? b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave? c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work. Jyri, were there some other options we discussed? Currently, the OMAP HDMI version does c). It's the easiest solution for us. Same for me, but checking the audio capability is done on audio streaming start only. When the HDMI output device is disconnected, the video and audio outputs don't need to be changed. I often switch off my TV set when I will not use my computer for a while, letting the computer itself running. When I get back and switch on back the TV set, video and audio are still there. Option a) is a bit problematic for us, as it requires the HDMI IP side to be fully operational, with the video output configured and enabled, as that is what drives the audio DMA. If we stop the video, I believe the audio DMA will freeze, and it'll lead to timeouts on the audio side. I haven't tried, but I believe we could program the HDMI IP to some safe default video mode if the cable is disconnected, and turn off the actual HDMI PHY, so that the audio side could work even if the HDMI stream is not going anywhere. I think it would be quite big change to how the HDMI driver works at the moment. But then, if the cable _is_ connected and the video mode is such that it cannot not support audio, I wonder if we can still fake the audio playback or will the HDMI IP get confused... AFAIK, the HDMI transmitters don't know if the video or audio is displayed/played by the external device(s). Only the user knows. BTW, you are talking about video modes without audio support. What are you thinking about? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line
[PATCH v5 6/8] net: can: c_can: Disable pins when CAN interface is down
DRA7 CAN IP suffers from a problem which causes it to be prevented
from fully turning OFF (i.e. stuck in transition) if the module was
disabled while there was traffic on the CAN_RX line.
To work around this issue we select the SLEEP pin state by default
on probe and use the DEFAULT pin state on CAN up and back to the
SLEEP pin state on CAN down.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/net/can/c_can/c_can.c | 37 +
drivers/net/can/c_can/c_can.h | 1 +
2 files changed, 38 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 8e78bb4..c80cb3d 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -35,6 +35,7 @@
#include linux/list.h
#include linux/io.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
#include linux/can.h
#include linux/can/dev.h
@@ -587,6 +588,21 @@ static int c_can_chip_config(struct net_device *dev)
return c_can_set_bittiming(dev);
}
+/*
+ * Selects the pinctrl state specified in the name.
+ */
+static void c_can_pinctrl_select_state(struct c_can_priv *priv,
+ const char *name)
+{
+ if (!IS_ERR(priv-pinctrl)) {
+ struct pinctrl_state *s;
+
+ s = pinctrl_lookup_state(priv-pinctrl, name);
+ if (!IS_ERR(s))
+ pinctrl_select_state(priv-pinctrl, s);
+ }
+}
+
static int c_can_start(struct net_device *dev)
{
struct c_can_priv *priv = netdev_priv(dev);
@@ -603,6 +619,8 @@ static int c_can_start(struct net_device *dev)
priv-can.state = CAN_STATE_ERROR_ACTIVE;
+ /* activate pins */
+ c_can_pinctrl_select_state(priv, PINCTRL_STATE_DEFAULT);
return 0;
}
@@ -611,6 +629,9 @@ static void c_can_stop(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
c_can_irq_control(priv, false);
+
+ /* deactivate pins */
+ c_can_pinctrl_select_state(priv, PINCTRL_STATE_SLEEP);
priv-can.state = CAN_STATE_STOPPED;
}
@@ -1244,6 +1265,22 @@ int register_c_can_dev(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
int err;
+ priv-pinctrl = devm_pinctrl_get(dev-dev.parent);
+ if (!IS_ERR(priv-pinctrl)) {
+ struct pinctrl_state *s;
+
+ /* Deactivate pins to prevent DRA7 DCAN IP from being
+* stuck in transition when module is disabled.
+* Pins are activated in c_can_start() and deactivated
+* in c_can_stop()
+*/
+ s = pinctrl_lookup_state(priv-pinctrl, PINCTRL_STATE_SLEEP);
+ if (!IS_ERR(s))
+ pinctrl_select_state(priv-pinctrl, s);
+ } else {
+ netdev_dbg(dev, failed to get pinctrl\n);
+ }
+
c_can_pm_runtime_enable(priv);
dev-flags |= IFF_ECHO; /* we support local echo */
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index c6715ca..3cedf48 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -210,6 +210,7 @@ struct c_can_priv {
u32 comm_rcv_high;
u32 rxmasked;
u32 dlc[C_CAN_MSG_OBJ_TX_NUM];
+ struct pinctrl *pinctrl;
};
struct net_device *alloc_c_can_dev(void);
--
1.8.3.2
--
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: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
On 13/11/14 17:00, Jean-Francois Moine wrote: When the tda998x is not operational, the CODEC knows it and reports an error to the audio subsystem on device open. But, once the tda998x has been started, it always stays operational, even without HDMI connection. What does started mean here? tda998x device/driver has been probed? The reason for the above is probably to handle hotplug? I.e. tda998x needs to be enabled always to detect HPD? Usually for OMAP, the HPD detection happens outside the HDMI IP. Thus the HDMI IP is turned fully off when the video is disabled. I believe tda998x could be used the same way, if the HPD pin is connected to a SoC GPIO instead of tda998x. and I saw only a few dependencies between the 2 subsystems: - the CODEC must know the transmitter parameters (DAIs - static -, audio constraints - dynamic -), The video mode (i.e. availability of audio) or the EDID (i.e. the supported audio parameters) may change at any time, so I presume in your series the video side will inform the codec of these changes at any point? Such changes occur only when the HDMI output device (TV) is replaced by The user can change the video mode at any time. The audio data packets are sent in the video blanking intervals, and if those intervals are too short, the video mode cannot support audio. If I'm not mistaken, officially only certain video modes defined in the HDMI spec support audio. an other one (manual cable exchange or HDMI switcher). I wonder if these changes are correctly treated in the HDMI transmitters, DRM core, DRM drivers, X11/wayland... HPD (which usually equals to cable change, but not always) is handled. a) Always keep the audio device operational, no matter what is the status of the video side. How should this work if the HDMI videomode or the HDMI monitor does not support audio? Is it desirable that the userspace has no idea that the audio is not actually going anywhere? b) Remove the audio device when audio support is not available. This kind of makes sense, as, well, there's no possibility for audio output. But maybe this is not how linux sound devices are supposed to behave? c) Return errors when playback is attempted when audio support is not available. Again, this kind of makes sense, as audio playback is not possible. But maybe this is also not how audio devices generally work. Jyri, were there some other options we discussed? Currently, the OMAP HDMI version does c). It's the easiest solution for us. Same for me, but checking the audio capability is done on audio streaming start only. Hmm, I understood you have option a)? You said I even let audio streaming start when the HDMI cable is disconnected. With audio support is not available I mean also the case when the cable is not connected, as then we don't have EDID information, and thus we don't have a HDMI monitor with audio support on the other end. So to clarify, our driver only has audio support available if: - we successfully read EDID - EDID shows it's a HDMI monitor - EDID shows it has audio support for the format we support (this we don't actually do yet) Otherwise we default to DVI, which means no audio. If, at any point, the situation changes to no audio support available, the audio playback is aborted and starting new audio playback fails. AFAIK, the HDMI transmitters don't know if the video or audio is displayed/played by the external device(s). Only the user knows. True. But the HDMI transmitter can know if the audio absolutely cannot be played, because there's no cable, or because the monitor says it doesn't support audio, or because the video mode cannot support audio, or because the HDMI output stream is disabled. So the question is, do we want/need to inform the userspace about those situations? Should a HDMI transmitted always look like it can play audio, even if it's clear it cannot? Again, I know very little about audio, but I think it would be nice that if I open the sound configuration window on my desktop, it'd show me that the HDMI audio device is disabled (because there's no cable). But perhaps that's a separate feature. We could have HDMI audio device always there and functional, but the desktop could get the information about HDMI cable connection some other way (DRM). And if the cable is not there, it knows that this particular audio device is also out, and thus doesn't show it (even if it's functional). BTW, you are talking about video modes without audio support. What are you thinking about? This I covered above. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] mtd: nand: omap: Fix NAND enumeration on 3430 LDP
On 11/13/2014 06:29 AM, Roger Quadros wrote: On 11/12/2014 08:02 PM, Tony Lindgren wrote: * pekon pe...@pek-sem.com [141109 11:31]: On Saturday 08 November 2014 04:18 AM, Tony Lindgren wrote: Right. I doubt anybody has bch8 rootfs on LDP.. And considering u-boot must be ham1 to boot at all, that's what we should change for the devices that do not have not standardized on bch8. My view on this is slightly different: - Lately, everyone seems to have migrated to BCH8. - Also HAM1 does not have strength to fix bitflips in aging NAND. So if someone already has OMAP3-LDP deployed on field then its NAND would have already aged to such an extend that HAM1 may not be sufficient. OK so it makes sense to keep it as BCH8 then. Would be nice to get the writing u-boot from kernel issue fixed somehow though as people are hitting that for sure. What about performance impact? OMAP3 doesn't have ELM module. So error location for BCH8 has to be done in software. My question is.. Moving back to HAM1 should be decided based on statistics rather than rule of breaking backward compatibility. So please review: (1) How many user of OMAP3-Zoom or other old boards complaining about using BCH8 in mainline kernel? OR 0 (2) How many users of OMAP3 legacy boards are migrating to newer kernel? Quite a few for sure, but are probably also using rootfs on MMC instead. At-least I have not, rather most of the OMAP3 users I interacted via TI's E2E forum wanted to migrate to BCH8 or even BCH16, as HAM1 was not sufficient for their usage. So whatever you decide on this topic, please be cautious that you don't re-invent work for yourself, as I did. It took me lot of time and testing effort on multiple boards to migrate HAM1 to BCH8, And add BCH16 for newer devices. Right no objections to using BCH8 for rootfs, except it stopped working over past year or so. This would be BCH8-sw on OMAP3 right? AM3xx uses BCH8-hw and that seems to work fine. So it seems nobody has used/tested BCH8-sw. A few years back, and I want to choose my words carefully when talking about error correction, BCH8-sw was working well enough for rootfs (I didn't induce any particular amount of errors or try and cause corner cases, etc, etc). And it seems the settings should be partition specific because of u-boot requiring HAM1. I don't think we have partition specific ECC scheme support in u-boot or kernel, so it will become messy to manage. That means we either stick with HAM1 for all partitions or don't support NAND boot at all and go with any other ECC scheme for OMAP3. This is indeed where life starts getting more complicated than what we allow for today in both U-Boot and Kernel, as I recall things anyhow. I think omap3 does (and I know am335x and later do) allow for saying ECC is all done on-chip and ROM should do nothing. But if you want to boot you're going to be limited to HAM1 (or in some cases BCH4? I didn't have to deal with these parts myself so second-hand recollections here) if you want to _boot_. So you'll be in that particular area of the part life-span where you have to worry about read disturbances and so forth. We _really_ do need (in both kernel and U-Boot) the ability to say a partition has ECC scheme X and another has scheme Y due to limitations on what you can boot from vs what you need for the (continued) life span of the device in question. -- Tom -- 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 v4 09/10] ARM: dts: am33xx: Update DCAN nodes
On Thu, Nov 13, 2014 at 02:22:50PM +0200, Roger Quadros wrote:
Add raminit-syscon property to specify the RAMINIT register.
Add clock information.
Rename can nodes from d_can to can to be compliant
with the ePAPR specs.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9f3058c..74fefa1 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -338,20 +338,24 @@
interrupts = 91;
};
- dcan0: d_can@481cc000 {
- compatible = bosch,d_can;
+ dcan0: can@481cc000 {
+ compatible = ti,am3352-d_can;
ti,hwmods = d_can0;
- reg = 0x481cc000 0x2000
- 0x44e10644 0x4;
+ reg = 0x481cc000 0x2000;
+ clocks = dcan0_fck;
+ clock-names = fck;
+ syscon-raminit = am33xx_control_module 0x644 0;
Yeah, I missed to write the mail that I disagreed with the dcan_0/1
compatible-properties of V3. The second parameter to syscon here is much
better!
Acked-by: Wolfram Sang w...@the-dreams.de
signature.asc
Description: Digital signature
Re: [PATCH v5 6/8] net: can: c_can: Disable pins when CAN interface is down
On 11/13/2014 04:23 PM, Roger Quadros wrote:
DRA7 CAN IP suffers from a problem which causes it to be prevented
from fully turning OFF (i.e. stuck in transition) if the module was
disabled while there was traffic on the CAN_RX line.
To work around this issue we select the SLEEP pin state by default
on probe and use the DEFAULT pin state on CAN up and back to the
SLEEP pin state on CAN down.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/net/can/c_can/c_can.c | 37 +
drivers/net/can/c_can/c_can.h | 1 +
2 files changed, 38 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index 8e78bb4..c80cb3d 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -35,6 +35,7 @@
#include linux/list.h
#include linux/io.h
#include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
#include linux/can.h
#include linux/can/dev.h
@@ -587,6 +588,21 @@ static int c_can_chip_config(struct net_device *dev)
return c_can_set_bittiming(dev);
}
+/*
+ * Selects the pinctrl state specified in the name.
+ */
+static void c_can_pinctrl_select_state(struct c_can_priv *priv,
+ const char *name)
+{
+ if (!IS_ERR(priv-pinctrl)) {
+ struct pinctrl_state *s;
+
+ s = pinctrl_lookup_state(priv-pinctrl, name);
+ if (!IS_ERR(s))
+ pinctrl_select_state(priv-pinctrl, s);
+ }
+}
+
static int c_can_start(struct net_device *dev)
{
struct c_can_priv *priv = netdev_priv(dev);
@@ -603,6 +619,8 @@ static int c_can_start(struct net_device *dev)
priv-can.state = CAN_STATE_ERROR_ACTIVE;
+ /* activate pins */
+ c_can_pinctrl_select_state(priv, PINCTRL_STATE_DEFAULT);
return 0;
}
@@ -611,6 +629,9 @@ static void c_can_stop(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
c_can_irq_control(priv, false);
+
+ /* deactivate pins */
+ c_can_pinctrl_select_state(priv, PINCTRL_STATE_SLEEP);
priv-can.state = CAN_STATE_STOPPED;
}
@@ -1244,6 +1265,22 @@ int register_c_can_dev(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
int err;
+ priv-pinctrl = devm_pinctrl_get(dev-dev.parent);
What's dev-dev.parent?
Ah, this is set by SET_NETDEV_DEV(dev, pdev-dev); Good work!
I thought we had to set priv-pinctrl in the platform.c.
+ if (!IS_ERR(priv-pinctrl)) {
+ struct pinctrl_state *s;
+
+ /* Deactivate pins to prevent DRA7 DCAN IP from being
+ * stuck in transition when module is disabled.
+ * Pins are activated in c_can_start() and deactivated
+ * in c_can_stop()
+ */
+ s = pinctrl_lookup_state(priv-pinctrl, PINCTRL_STATE_SLEEP);
+ if (!IS_ERR(s))
+ pinctrl_select_state(priv-pinctrl, s);
+ } else {
+ netdev_dbg(dev, failed to get pinctrl\n);
+ }
+
The above can be replace by this?
c_can_pinctrl_select_state(priv, PINCTRL_STATE_SLEEP)
Then we don't have the worrying looking error message if there isn't any
pinctrl, e.g. for the PCI driver with pinctrl enabled in the Kernel.
I just stumbled over pinctrl_pm_select_sleep_state(), is it possible to
integrate this into runtime pm?
http://lxr.free-electrons.com/source/drivers/pinctrl/core.c#L1282
c_can_pm_runtime_enable(priv);
dev-flags |= IFF_ECHO; /* we support local echo */
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index c6715ca..3cedf48 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -210,6 +210,7 @@ struct c_can_priv {
u32 comm_rcv_high;
u32 rxmasked;
u32 dlc[C_CAN_MSG_OBJ_TX_NUM];
+ struct pinctrl *pinctrl;
};
struct net_device *alloc_c_can_dev(void);
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 8/8] net: can: c_can: Add support for TI am3352 DCAN
On Fri, Nov 07, 2014 at 04:49:22PM +0200, Roger Quadros wrote: AM3352 SoC has 2 DCAN modules. Add compatible id and raminit driver data for am3352 DCAN. Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Wolfram Sang w...@the-dreams.de signature.asc Description: Digital signature
Re: N900 modem support in 3.18-rc1
Hi! I actually had pm=0 on the command line, but I removed it now, and no change: [...] Let me try with explicit =1. .. aha, that helps. Thanks! mh seems I actually missed to make 1 the default value. I will prepare a patch for that. I assume, that the example ofono commands work for you now? Yes, it now works great. Do you have an example client that can talk to ofonod? I have not yet played with userland stuff. You could try telepathy-ring, which integrates the ofono into the telepathy framework. Ok, I took a look, and telepathy-ring is not in debian, and has a lot of dependencies. OTOH ofono seems pretty reasonable. So I played a bit, and result is python/pygtk gui which can receive an sms, initiate a call, and report missed call. If someone wants to play, source is at https://gitorious.org/tui/tui/source/b6141107e9341a1412720aed4b0d09143dfa2f4e:ofone Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: N900 modem support in 3.18-rc1
On Fri 2014-11-07 09:04:52, Ivaylo Dimitrov wrote: On 7.11.2014 01:01, Pali Rohár wrote: For voice calls you need: * kernel driver cmt-speech (or it has some new name) * cmt-speech userspace library (communication with kernel) * pulseaudio modules which are using that library Freemangordon (Ivaylo Dimitrov, CCed) should know more about it, specially about pulseaudio modules... I have a patch for cmt-speech on top of nokia-modem driver living somewhere on my HDD, but I guess it is better Sebastian to make such a patch (Sebastian, no?). Sebastian is quiet, can we have the patch? :-). About the pulseaudio stuff - we're still in process of REing it, so far there are 2 out of 3 closed Nokia modules ready (https://gitorious.org/pulseaudio-nokia), but the last one, which is the one used for voice calls is still not ready and will take it a while :). Ok, is there a way I could help? Pretty much everything else works with opensource drivers... Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCH v2 1/5] video: omapdss: Add opa362 driver
Hi,
Am 13.11.2014 um 12:51 schrieb Tomi Valkeinen tomi.valkei...@ti.com:
On 13/11/14 00:10, Marek Belisko wrote:
opa362 is amplifier for video and can be connected to the tvout pads
of the OMAP3. It has one gpio control for enable/disable of the output
(high impedance).
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
drivers/video/fbdev/omap2/displays-new/Kconfig | 6 +
drivers/video/fbdev/omap2/displays-new/Makefile| 1 +
.../fbdev/omap2/displays-new/amplifier-opa362.c| 343
+
I think it would be better to rename this to encoder-opa362.c. It's not
When developing this driver we did simply rename the encoder-tfp410 file,
but thent hough that it does not fit into the „encoder“ category, because we
would expect something digital or digital to analog „encoding“ which it does
not.
encoder as such, but it falls into the same category.
But we can change it.
include/video/omap-panel-data.h| 12 +
4 files changed, 362 insertions(+)
create mode 100644 drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
diff --git a/drivers/video/fbdev/omap2/displays-new/Kconfig
b/drivers/video/fbdev/omap2/displays-new/Kconfig
index e6cfc38..211b3ec 100644
--- a/drivers/video/fbdev/omap2/displays-new/Kconfig
+++ b/drivers/video/fbdev/omap2/displays-new/Kconfig
@@ -1,6 +1,12 @@
menu OMAP Display Device Drivers (new device model)
depends on OMAP2_DSS
+config DISPLAY_AMPLIFIER_OPA362
Here also use ENCODER instead.
+tristate external analog amplifier with output disable/high-Z
(e.g. OPA362)
+help
+ Driver to enable an external analog TV amplifier (e.g. OPA362)
+ through a GPIO.
The indentation above seems funny.
The text looks a bit odd. So is this a driver for OPA362, or is this a
generic driver for any similar devices? Most of the names and code makes
me think this is a driver for OPA362, but the text above quite clearly
gives the impression that this is a driver for any analog video amp,
with single enable gpio.
Hm. We can imagine that there are other devices with similar functionality
and gpio but we have not tested any. So it is indeed better to describe it as
a pure OPA362 driver.
+
config DISPLAY_ENCODER_TFP410
tristate TFP410 DPI to DVI Encoder
help
diff --git a/drivers/video/fbdev/omap2/displays-new/Makefile
b/drivers/video/fbdev/omap2/displays-new/Makefile
index 0323a8a..b311542 100644
--- a/drivers/video/fbdev/omap2/displays-new/Makefile
+++ b/drivers/video/fbdev/omap2/displays-new/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_DISPLAY_AMPLIFIER_OPA362) += amplifier-opa362.o
obj-$(CONFIG_DISPLAY_ENCODER_TFP410) += encoder-tfp410.o
obj-$(CONFIG_DISPLAY_ENCODER_TPD12S015) += encoder-tpd12s015.o
obj-$(CONFIG_DISPLAY_CONNECTOR_DVI) += connector-dvi.o
diff --git a/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
b/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
new file mode 100644
index 000..8065a28
--- /dev/null
+++ b/drivers/video/fbdev/omap2/displays-new/amplifier-opa362.c
@@ -0,0 +1,343 @@
+/*
+ * OPA362 analog video amplifier with output/power control
+ *
+ * Copyright (C) 2014 Golden Delicious Computers
+ * Author: H. Nikolaus Schaller h...@goldelico.com
+ *
+ * based on encoder-tfp410
+ *
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Tomi Valkeinen tomi.valkei...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ */
+
+#include linux/gpio.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of_gpio.h
+
+#include video/omapdss.h
+#include video/omap-panel-data.h
+
+struct panel_drv_data {
+struct omap_dss_device dssdev;
+struct omap_dss_device *in;
+
+int enable_gpio;
+
+struct omap_video_timings timings;
+};
+
+#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
+
+static int opa362_connect(struct omap_dss_device *dssdev,
+struct omap_dss_device *dst)
+{
+struct panel_drv_data *ddata = to_panel_data(dssdev);
+struct omap_dss_device *in = ddata-in;
+int r;
+
+dev_dbg(dssdev-dev, connect\n);
+
+if (omapdss_device_is_connected(dssdev))
+return -EBUSY;
+
+r = in-ops.atv-connect(in, dssdev);
+if (r)
+return r;
+
+dst-src = dssdev;
+dssdev-dst = dst;
+
+return 0;
+}
+
+static void opa362_disconnect(struct omap_dss_device *dssdev,
+struct omap_dss_device *dst)
+{
+struct panel_drv_data *ddata = to_panel_data(dssdev);
+struct omap_dss_device *in = ddata-in;
+
+dev_dbg(dssdev-dev, disconnect\n);
+
+WARN_ON(!omapdss_device_is_connected(dssdev));
+if (!omapdss_device_is_connected(dssdev))
+
Re: [PATCH v2 1/5] video: omapdss: Add opa362 driver
On 13/11/14 18:25, Dr. H. Nikolaus Schaller wrote: Hi, Am 13.11.2014 um 12:51 schrieb Tomi Valkeinen tomi.valkei...@ti.com: On 13/11/14 00:10, Marek Belisko wrote: opa362 is amplifier for video and can be connected to the tvout pads of the OMAP3. It has one gpio control for enable/disable of the output (high impedance). Signed-off-by: H. Nikolaus Schaller h...@goldelico.com --- drivers/video/fbdev/omap2/displays-new/Kconfig | 6 + drivers/video/fbdev/omap2/displays-new/Makefile| 1 + .../fbdev/omap2/displays-new/amplifier-opa362.c| 343 + I think it would be better to rename this to encoder-opa362.c. It's not When developing this driver we did simply rename the encoder-tfp410 file, but thent hough that it does not fit into the „encoder“ category, because we would expect something digital or digital to analog „encoding“ which it does not. That is true, but we already have other encoders like encoder-tpd12s015.c, which also do not encode. encoder in this context means something that takes a video input, and has a video output. In contrast to a panel or a connector. + + in-ops.atv-set_timings(in, ddata-timings); + /* fixme: should we receive the invert from our consumer, i.e. the connector? */ + in-ops.atv-invert_vid_out_polarity(in, true); Well this does seem to be broken. I don't know what the answer to the question above is, but the code doesn't work properly. In the opa362_invert_vid_out_polarity function below, you get the invert boolean from the connector. This you pass to the OMAP venc. However, above you always override that value in venc with true. So, either the invert_vid_out_polarity value has to be always true or false, because _OPA362_ requires it to be true or false, OR you need use the value from the connector. Seeing the comment in opa362_invert_vid_out_polarity, my guess is the latter, and the call above should be removed. Yes, you are right - this is not systematic. But the problem is that we can’t ask the connector here what it wants to see. It might (or might not) call our opa362_invert_vid_out_polarity() later which we can then forward to overwrite the inital state of this opa362_enable(). You don't need to ask. The connector calls invert_vid_out_polarity before enabling the output. You can just pass it forward inverted, as you already do in this driver. If it doesn't, it's either a bug or you can just rely on the value that is already programmed to venc. We are going to support only DT boot at some point. Thus I think the whole platform data code should be left out. Is there already a decision? I think it should not be done before. And it does not harm to still have it. It's just a matter of time. I don't accept any new boards using platform data for display, or new display drivers using platform data, because I don't want to spend my time converting them later. And as this is a new driver, no existing board can be using the opa362 platform_data. So we can support DT only. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] ARM: OMAP3+: DPLL: fix set_rate logic
On Fri, 3 Oct 2014, Tero Kristo wrote: OMAP3+ DPLL code is currently using set_rate op to change DPLL rates. This is kind of wrong, as it also involves changing DPLL parent in certain cases (switch between locked mode - bypass mode.) This set fixes these issues by introducing the support of determine_rate and set_rate_and_parent ops for the DPLL clocks. Also introduces support for set_parent, which just switches a DPLL between locked - bypass modes. Thanks, queued for v3.19. - Paul -- 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: [PATCHv6 4/5] hwspinlock/core: add common OF helpers
Hi Ohad,
On 11/13/2014 04:03 AM, Ohad Ben-Cohen wrote:
Hi Suman,
On Wed, Nov 12, 2014 at 9:32 PM, Suman Anna s-a...@ti.com wrote:
Is this the validation you mentioned which requires the existence of
hwspinlock/core: maintain a list of registered hwspinlock banks ?
Well, not exactly. The validation is on the following segment,
+ id = of_hwspin_lock_simple_xlate(bank, args);
+ if (id 0 || id = bank-num_locks) {
+ ret = -EINVAL;
+ goto out;
+ }
I'm not entirely convinced that this justifies adding the proposed
linked list. Can't we can get the base_id and number of locks by
traversing the DT?
No, not always, because, either of them can be optional between
different platform implementations. For example, on OMAP, the number of
locks is read from an IP register, and not coded in DT. Similarly,
base_id can be optional on SoCs that don't have multiple IP instances.
The only place the hwspinlock core knows both of them for sure is at the
device registration time, but the core only stores the locks and not the
devices at the moment. Any operation on the device is not possible
without knowing the exact global lock we are dealing with, and this API
is about returning that exact global lock id.
That said, it is also needed to provide the support for deferred probing
without changing the return code conventions on the existing API.
Here too, adding a data structure maintaining memory objects and
taking care of it life cycle seems a bit overkill for anything to do
with return values.
IMHO, this life cycle management is not that complicated, it is managed
alongside the addition/removal of the locks during the device
registration/unregistration time.
Yes, and wouldn't that require that the id is validated? It just cannot
return any return value, and expect it will be verified somewhere else
or in a following API call. Not doing the validation unnecessarily
complicates the system usage of a lock as you are sharing an invalid
lock to a remote processor and then you have two validation failure
paths on different processors.
Validation is great but I'm still not convinced it can't be done
without maintaining another data structure.
Please show me specific technical issues that can't be resolved
without adding the proposed linked list.
Same as above.
regards
Suman
--
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 V3 3/3] mfd: palmas: Add support for optional wakeup
* Thomas Gleixner t...@linutronix.de [141113 02:04]:
Tony,
On Thu, 6 Nov 2014, Tony Lindgren wrote:
Any comments on the patch below? Let me know if you want to keep the
devm stuff out of kernel/irq/manage.c.
Sorry, this slipped through the cracks.
No problem I should have posted it as a separate thread anyways.
+static int setup_wakeirq(struct device *dev, unsigned int wakeirq,
+ unsigned long wakeflags, bool devm)
+{
+ int ret;
+
+ if (!(dev wakeirq)) {
+ pr_err(Missing device or wakeirq for %s irq %d\n,
+dev_name(dev), wakeirq);
+ return -EINVAL;
+ }
+
+ if (!(wakeflags
+ (IRQF_TRIGGER_LOW | IRQF_TRIGGER_HIGH | IRQF_ONESHOT))) {
+ pr_err(Invalid wakeirq for %s irq %d, must be level oneshot\n,
+dev_name(dev), wakeirq);
This looks odd.
Why do you want to enforce LEVEL and ONESHOT? I can see the point for
ONESHOT, but I'm wondering about the requirement for level.
Now if you really want to enforce level AND oneshot, your check is
wrong as it will not trigger on
wakeflags = IRQF_TRIGGER_LOW;
wakeflags = IRQF_TRIGGER_HIGH;
wakeflags = IRQF_ONESHOT;
Not what you really want, right?
Hmm yes that's right. I've just added a warning about not replaying
device interrupts in case somebody passes EDGE. Not sure how useful
that is, but might get somebody to add more features if really needed.
+int request_wake_irq(struct device *dev, unsigned int wakeirq,
+ unsigned long wakeflags)
+{
+ return setup_wakeirq(dev, wakeirq, wakeflags, false);
+}
+EXPORT_SYMBOL(request_wake_irq);
_GPL please
Sure.
+
+int devm_request_wake_irq(struct device *dev, unsigned int wakeirq,
+ unsigned long wakeflags)
+{
+ return setup_wakeirq(dev, wakeirq, wakeflags, false);
Shouldnt that have devm = true?
Oops thanks for catching that. As the devres stuff is separate, I've
updated the patch to keep it that way by adding a minimal manage.h.
This avoids including internals.h in devres.c. Does that seem usable
for you?
Regards,
Tony
8 -
From: Tony Lindgren t...@atomide.com
Date: Tue, 11 Nov 2014 07:53:55 -0800
Subject: [PATCH] genirq: Add support for wake-up interrupts to fix irq reentry
issues in drivers
As pointed out by Thomas Gleixner, at least omap wake-up interrupts
have an issue with re-entrant interrupts because the wake-up interrupts
are now handled as a secondary interrupt controller. Further, the
wake-up interrupt just needs wake the system at least for omaps. So we
should make the wake-up interrupt handling generic.
Note that at least initially we are keeping things simple by assuming the
wake-up interrupt is level sensitive, and the device pm_runtime_resume()
can deal with the situation, and no replaying of the lost device interrupts
is needed.
After tinkering with replaying of the lost device interrupts, my opinion is
that it should be avoided because of the issues listed in the comments of
this patch.
Let's also add a minimal manage.h to allow us keeping the separation
of devm functions and without having to include internals.h in devres.c.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -139,11 +139,15 @@ extern int __must_check
request_percpu_irq(unsigned int irq, irq_handler_t handler,
const char *devname, void __percpu *percpu_dev_id);
+struct device;
+
+extern int __must_check
+request_wake_irq(struct device *dev, unsigned int wakeirq,
+unsigned long irqflags);
+
extern void free_irq(unsigned int, void *);
extern void free_percpu_irq(unsigned int, void __percpu *);
-struct device;
-
extern int __must_check
devm_request_threaded_irq(struct device *dev, unsigned int irq,
irq_handler_t handler, irq_handler_t thread_fn,
@@ -163,6 +167,10 @@ devm_request_any_context_irq(struct device *dev, unsigned
int irq,
irq_handler_t handler, unsigned long irqflags,
const char *devname, void *dev_id);
+extern int __must_check
+devm_request_wake_irq(struct device *dev, unsigned int wakeirq,
+ unsigned long irqflags);
+
extern void devm_free_irq(struct device *dev, unsigned int irq, void *dev_id);
/*
--- a/kernel/irq/devres.c
+++ b/kernel/irq/devres.c
@@ -3,6 +3,8 @@
#include linux/device.h
#include linux/gfp.h
+#include manage.h
+
/*
* Device resource management aware IRQ request/free implementation.
*/
@@ -118,6 +120,30 @@ int devm_request_any_context_irq(struct device *dev,
unsigned int irq,
EXPORT_SYMBOL(devm_request_any_context_irq);
/**
+ * devm_request_wake_irq - request a wake-up interrupt for a device
+ * @dev: device to wake on the wake-up interrupt
+ * @wakeirq: wake-up interrupt for the device
+ * @wakeirq: wake-up interrupt flags
+
Re: [PATCHv2] rpmsg: compute number of buffers to allocate from vrings
Hi Ohad, On 09/16/2014 01:33 PM, Suman Anna wrote: The buffers to be used for communication are allocated during the rpmsg virtio driver's probe, and the total number of buffers is currently hard-coded to 512. The vring configuration can vary from one platform to another or between different remote processors. The setup of the receive buffers will throw a WARN_ON if the associated vrings are configured with less than 256 buffers (in each direction). So, adjust this hard-coded value to rely on the number of buffers the virtqueue vring is setup with, but also limit to use 256 buffers at most in each direction to avoid wacky resource tables consuming up unreasonable memory. NOTE: The number of buffers is already assumed to be symmetrical in each direction, and that logic is not unchanged. Signed-off-by: Suman Anna s-a...@ti.com --- v2 changes: - add upper limit on buffers and update comments - revise patch description Any comments on this one, if not can you pick this up for 3.19? regards Suman -- 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: N900 modem support in 3.18-rc1
* Pavel Machek pa...@ucw.cz [141113 08:23]: Hi! I actually had pm=0 on the command line, but I removed it now, and no change: [...] Let me try with explicit =1. .. aha, that helps. Thanks! mh seems I actually missed to make 1 the default value. I will prepare a patch for that. I assume, that the example ofono commands work for you now? Yes, it now works great. Do you have an example client that can talk to ofonod? I have not yet played with userland stuff. You could try telepathy-ring, which integrates the ofono into the telepathy framework. Ok, I took a look, and telepathy-ring is not in debian, and has a lot of dependencies. OTOH ofono seems pretty reasonable. So I played a bit, and result is python/pygtk gui which can receive an sms, initiate a call, and report missed call. If someone wants to play, source is at https://gitorious.org/tui/tui/source/b6141107e9341a1412720aed4b0d09143dfa2f4e:ofone Pavel, care to fill in the the following type patch with some instructions in the description now that you got it working? I did not have luck yet when I tried. I got the /dev/cmt/* entries after adding pm=1 param, but no luck scanning any networks. Regards, Tony 8 - ARM: omap2plus_defconfig: Enable n900 modem as loadable modules --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -88,6 +88,7 @@ CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y # CONFIG_INET_LRO is not set CONFIG_NETFILTER=y +CONFIG_PHONET=m CONFIG_CAN=m CONFIG_CAN_C_CAN=m CONFIG_CAN_C_CAN_PLATFORM=m @@ -158,6 +159,7 @@ CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y +CONFIG_USB_CDC_PHONET=m CONFIG_LIBERTAS=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_SDIO=m @@ -197,6 +199,11 @@ CONFIG_HW_RANDOM=y CONFIG_I2C_CHARDEV=y CONFIG_SPI=y CONFIG_SPI_OMAP24XX=y +CONFIG_HSI=m +CONFIG_OMAP_SSI=m +CONFIG_NOKIA_MODEM=m +CONFIG_SSI_PROTOCOL=m +CONFIG_HSI_CHAR=m CONFIG_PINCTRL_SINGLE=y CONFIG_DEBUG_GPIO=y CONFIG_GPIO_SYSFS=y @@ -312,9 +319,11 @@ CONFIG_USB_CONFIGFS_ECM=y CONFIG_USB_CONFIGFS_ECM_SUBSET=y CONFIG_USB_CONFIGFS_RNDIS=y CONFIG_USB_CONFIGFS_EEM=y +CONFIG_USB_CONFIGFS_PHONET=y CONFIG_USB_CONFIGFS_MASS_STORAGE=y CONFIG_USB_CONFIGFS_F_LB_SS=y CONFIG_USB_CONFIGFS_F_FS=y +CONFIG_USB_G_NOKIA=m CONFIG_MMC=y CONFIG_SDIO_UART=y CONFIG_MMC_OMAP=y @@ -359,6 +368,7 @@ CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y +CONFIG_CONFIGFS_FS=y CONFIG_JFFS2_FS=y CONFIG_JFFS2_SUMMARY=y CONFIG_JFFS2_FS_XATTR=y -- 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 v4 06/10] ARM: dts: am4372: Add DCAN nodes
* Marc Kleine-Budde m...@pengutronix.de [141113 06:55]:
On 11/13/2014 03:49 PM, Roger Quadros wrote:
On 11/13/2014 04:44 PM, Marc Kleine-Budde wrote:
On 11/13/2014 03:40 PM, Roger Quadros wrote:
On 11/13/2014 04:07 PM, Marc Kleine-Budde wrote:
On 11/13/2014 01:22 PM, Roger Quadros wrote:
The SoC contains 2 DCAN modules. Add them.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi
b/arch/arm/boot/dts/am4372.dtsi
index 899c57c..12fb1db 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -901,6 +901,28 @@
compatible = mmio-sram;
reg = 0x4030 0x4; /* 256k */
};
+
+ dcan0: can@481cc000 {
+ compatible = ti,am3352-d_can;
You should add ti,am4372-d_can as first compatible here.
We don't have a separate compatible id for am4372-d_can
as it the IP exactly same as am3352-d_can.
Having the ti,am4372-d_can compatible gives you the freedom to add
some spacial handling for the IP if there turns that you need to without
needing to modify the device tree. (We do this on imx.)
Agreed. On OMAP platforms we don't add new compatible IDs unless we really
need to.
Can we add ti,am4372-d_can even if it is not mentioned in
Documentation/devicetree/bindings?
Tony what is your preference?
I don't insist, do it the Omap way :)
I agree it's good to add if we need to add custom handling later on.
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] mtd: nand: omap: Fix NAND enumeration on 3430 LDP
* Tom Rini tr...@ti.com [141113 08:02]: On 11/13/2014 06:29 AM, Roger Quadros wrote: On 11/12/2014 08:02 PM, Tony Lindgren wrote: Right no objections to using BCH8 for rootfs, except it stopped working over past year or so. This would be BCH8-sw on OMAP3 right? AM3xx uses BCH8-hw and that seems to work fine. So it seems nobody has used/tested BCH8-sw. A few years back, and I want to choose my words carefully when talking about error correction, BCH8-sw was working well enough for rootfs (I didn't induce any particular amount of errors or try and cause corner cases, etc, etc). Yes it still works, but for LDP it broke because of the regression discussed in $thread. And it seems the settings should be partition specific because of u-boot requiring HAM1. I don't think we have partition specific ECC scheme support in u-boot or kernel, so it will become messy to manage. That means we either stick with HAM1 for all partitions or don't support NAND boot at all and go with any other ECC scheme for OMAP3. This is indeed where life starts getting more complicated than what we allow for today in both U-Boot and Kernel, as I recall things anyhow. I think omap3 does (and I know am335x and later do) allow for saying ECC is all done on-chip and ROM should do nothing. But if you want to boot you're going to be limited to HAM1 (or in some cases BCH4? I didn't have to deal with these parts myself so second-hand recollections here) if you want to _boot_. So you'll be in that particular area of the part life-span where you have to worry about read disturbances and so forth. We _really_ do need (in both kernel and U-Boot) the ability to say a partition has ECC scheme X and another has scheme Y due to limitations on what you can boot from vs what you need for the (continued) life span of the device in question. Totally. Updating the bootloader should be doable safely from userspace after booting the kernel. Or else should disable those partitions for kernel because people are trashing their u-boot while trying to update. 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
[PATCH] ARM: Gumstix DuoVero: Bind vdac regulator to hdmi node
The HDMI node does not have a power supply attached. As a result its
power regulator, VDAC, shuts off on boot and screen loses signal.
This attaches VDAC (vdda_hdmi_dac) to HDMI's vdda-supply.
Signed-off-by: Adam YH Lee adam.yh@gmail.com
---
arch/arm/boot/dts/omap4-duovero-parlor.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap4-duovero-parlor.dts
b/arch/arm/boot/dts/omap4-duovero-parlor.dts
index 6dc84d9..1a78f01 100644
--- a/arch/arm/boot/dts/omap4-duovero-parlor.dts
+++ b/arch/arm/boot/dts/omap4-duovero-parlor.dts
@@ -177,6 +177,7 @@
hdmi {
status = ok;
+ vdda-supply = vdac;
pinctrl-names = default;
pinctrl-0 = dss_hdmi_pins;
--
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: N900 modem support in 3.18-rc1
Hi, On Thu, Nov 13, 2014 at 09:45:36AM -0800, Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [141113 08:23]: OTOH ofono seems pretty reasonable. So I played a bit, and result is python/pygtk gui which can receive an sms, initiate a call, and report missed call. If someone wants to play, source is at https://gitorious.org/tui/tui/source/b6141107e9341a1412720aed4b0d09143dfa2f4e:ofone Pavel, care to fill in the the following type patch with some instructions in the description now that you got it working? Could we even have some permanent instructions under Documentation/? I did not have luck yet when I tried. I got the /dev/cmt/* entries after adding pm=1 param, but no luck scanning any networks. I haven't tested anything yet, but looking forward to do that during the weekend... Sounds pretty exciting. :-) A. -- 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 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
* Tomi Valkeinen tomi.valkei...@ti.com [141113 03:33]: On 12/11/14 17:02, Tony Lindgren wrote: And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple places in the kernel. I wonder if adding a pinmux entry for it could cause some rather odd problems. They can all use pinctrl-single no problem. Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux, and we have code in mach-omap2 that also touch DEVCONF1, without any knowledge (and locking) between those... Hmm yeah the McBSP clock mux could be racy as the mux register for McBSP is treated as a clock. This register muxes the clock between external pin and internal clock. Considering that this should be selectable at board level as the external clock probably needs to be used if level shifters are being used, it should be really handled by pinctrl-single. The other use for hsmmc.c and pdata-quirks.c for the one time mux for MMC clock from the MMC clock pin. That can be done with pinctrl-single from the MMC driver too for DT based booting. Then we just have the save and restore of the registers for off-idle. So _maybe_ that's not an issue, as the pinmux config we have here is fixed, and done once at boot time, and maybe the code in mach-omap2 that touch DEVCONF1 is also ran just once and not at the same time as the pinmux. But I don't know if that's so. It seems we could just do a read-only check for McBSP in the clock code for the mux register, or even completely drop that code from cclock3xxx_data.c and start using the pinctrl for that mux. Paul Tero, got any comments here? 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 11/13] arm: dts: dra7: add DMA properties for UART
On 11/05/2014 08:43 PM, Lennart Sorensen wrote: I managed to get something dma related on uart3. But it isn't happy: [ 95.577401] DMA misaligned error with device 53 repeated many times. I wonder if the dma support isn't quite working for the omap572x yet in this tree (ti's 3.12.y tree), or maybe it is picky and the driver still needs a bit of work. misaligned dma? I haven't seen any alignment requirement for SDMA/EDMA and I haven't seen this error on beagle board, am335x-evm or dra7-evm. I have had no issues on uart7 and 8 without dma. So basically what you are saying is that DMA (no matter which channel) gives you this error and without DMA it works fine? 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: [PATCHv6 4/5] hwspinlock/core: add common OF helpers
Hi Suman, On Thu, Nov 13, 2014 at 7:38 PM, Suman Anna s-a...@ti.com wrote: No, not always, because, either of them can be optional between different platform implementations. For example, on OMAP, the number of locks is read from an IP register, and not coded in DT. Similarly, base_id can be optional on SoCs that don't have multiple IP instances. It can, but base_id isn't optional today --- it must be provided via platform_data --- and I'm not sure we should implicitly change this semantics while moving to DT. We never guessed the base_id before, even if there was only a single IP instance, and I'm not convinced we should start doing it now. About the number of locks - why do we even need it at this point? the global lock id should just be base_id + the lock index. IMHO, this life cycle management is not that complicated It's always very easy to add code, really. It is never complicated. But then gradually the code becomes harder to maintain, debug, and change. On the contrary, achieving the same functionality with less code is always harder. But when we get there, the results are pretty satisfying. In this case I still feel the extra linked list is redundant. Please try it: ditch the hwspinlock/core: maintain a list of registered hwspinlock banks patch, and replace of_hwspin_lock_get_id with a slim method that just returns the base_id + the lock index. Let me know if it works for you. Thanks, Ohad. -- 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: [PATCHv6 4/5] hwspinlock/core: add common OF helpers
Hi Ohad,
On 11/13/2014 01:45 PM, Ohad Ben-Cohen wrote:
Hi Suman,
On Thu, Nov 13, 2014 at 7:38 PM, Suman Anna s-a...@ti.com wrote:
No, not always, because, either of them can be optional between
different platform implementations. For example, on OMAP, the number of
locks is read from an IP register, and not coded in DT. Similarly,
base_id can be optional on SoCs that don't have multiple IP instances.
It can, but base_id isn't optional today --- it must be provided via
platform_data ---
That was the case before DT, right. As it is, the hwspinlock core has no
knowledge of platform_data, it was used by the individual implementation
drivers to supply the base_id in the registration API.
The platform_data will/should become obsolete with DT devices.
and I'm not sure we should implicitly change this
semantics while moving to DT. We never guessed the base_id before,
even if there was only a single IP instance, and I'm not convinced we
should start doing it now.
OK, if we make hwlock-base-id mandatory in DT, we will get past 1
problem (that of looking up base-id for a specific device).
About the number of locks - why do we even need it at this point? the
global lock id should just be base_id + the lock index.
The number of locks would still be needed for validation purposes.
OK, lets take an example. I have say 2 device instances, say
hwlock1: hwlock@0 {
hwlock-num-locks = 32
hwlock-base-id = 0;
#hwlock-cells = 1;
};
hwlock2: hwlock@0 {
hwlock-num-locks = 32
hwlock-base-id = 32;
#hwlock-cells = 1;
};
some-client {
hwlocks = hwlock1 32, hwlock2 0;
};
The first args value is incorrect, and I expect the API to return an
error. I don't think the API can make assumptions that all passed in
values will be correct. What do you suggest that the API do here?
The above locks are equivalent if we forgo checking.
IMHO, this life cycle management is not that complicated
It's always very easy to add code, really. It is never complicated.
But then gradually the code becomes harder to maintain, debug, and
change.
On the contrary, achieving the same functionality with less code is
always harder. But when we get there, the results are pretty
satisfying.
In this case I still feel the extra linked list is redundant.
Please try it: ditch the hwspinlock/core: maintain a list of
registered hwspinlock banks patch, and replace of_hwspin_lock_get_id
with a slim method that just returns the base_id + the lock index. Let
me know if it works for you.
Yeah, it will work (provided base-id is mandatory) and we drop the
support for
1. phandle args-specifier validation
2. Deferred probing
One solution to handle #1 is to also make the hwlock-num-locks property
also mandatory (even though it could have been read from a register and
I wonder what implementations should do if there is a mismatch between
DT provided value and the value read from IP register). I am not sure
what the DT maintainers' stance is on this, as we are forcing that to
solve an implementation detail in the hwspinlock core.
And, how do you propose we solve the problem of deferred probing? This
was the solution that is resolving both the problems without changing
return codes on existing API (that was my first attempt, but you
preferred not to change API return convention).
Kumar, Mark,
Any comments here?
regards
Suman
--
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 11/13] arm: dts: dra7: add DMA properties for UART
On Thu, Nov 13, 2014 at 07:34:09PM +0100, Sebastian Andrzej Siewior wrote: misaligned dma? I haven't seen any alignment requirement for SDMA/EDMA and I haven't seen this error on beagle board, am335x-evm or dra7-evm. Well I am using the am5728, so it should be the same as the dra7-evm. So basically what you are saying is that DMA (no matter which channel) gives you this error and without DMA it works fine? Yes. I am trying to get the 3.14 kernel tree going, just as soon as I figure out which config setting makes the timer probe not crash (it works with the default config that enables every omap ever made, but I want a cleaner build than that). -- Len Sorensen -- 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 V3 3/3] mfd: palmas: Add support for optional wakeup
On Thu, 13 Nov 2014, Tony Lindgren wrote:
Oops thanks for catching that. As the devres stuff is separate, I've
updated the patch to keep it that way by adding a minimal manage.h.
This avoids including internals.h in devres.c. Does that seem usable
for you?
What's wrong with internals.h? devres.c is core code, so it is not
affected of the ban to include internals.h :)
+/**
+ * init_disabled_wakeirq - initialize a wake-up interrupt for a device
+ * @dev: device to wake up on the wake-up interrupt
+ * @wakeirq: wake-up interrupt for the device
+ * @wakeflags: wake-up interrupt flags
+ *
+ * Note that the wake-up interrupt starts disabled. The wake-up interrupt
+ * is typically enabled from the device pm_runtime_suspend() and disabled
+ * again in the device pm_runtime_resume(). For runtime PM, the wake-up
+ * interrupt should be always enabled, and for device suspend and resume,
+ * the wake-up interrupt should be enabled depending on the device specific
+ * configuration for device_can_wakeup().
+ *
+ * Note also that we are not resending the lost device interrupts.
+ * We assume that the wake-up interrupt just needs to wake-up the device,
+ * and then device pm_runtime_resume() can deal with the situation.
+ *
+ * There are at least the following reasons to not resend the lost device
+ * interrupts automatically based on the wake-up interrupt:
+ *
+ * 1. There can be interrupt reentry issues calling the device interrupt
+ * based on the wake-up interrupt if done in the device driver. It
+ * could be done with check_irq_resend() after checking the device
+ * interrupt mask if we really wanted to though.
+ *
+ * 2. The device interrupt handler would need to be set up properly with
+ * pm_runtime_irq_safe(). Ideally you don't want to call pm_runtime
+ * calls from the device interrupt handler at all.
+ *
+ * 3. The IRQ subsystem may not know if it's safe to call the device
+ * interrupt unless the driver updates the interrupt status with
+ * disable_irq() and enable_irq() in addition to just disabling the
+ * interrupt at the hardware level in the device registers.
+ *
+ * So if replaying the lost device interrupts is absolutely needed from the
+ * hardware point of view, it's probably best to set up a completely
+ * separate wake-up interrupt handler for the wake-up interrupt in the
+ * device driver because of the reasons above.
Can we please kill this last paragraph? I'm already seeing the
gazillion of I think it is required to do so for my s special
chip implementations in random drivers which all get it wrong again.
So I'd rather provide a mechanism upfront which lets the driver know
that the wakeup interrupt originated from that device, i.e. let the
wake up handler call
pm_wakeup_irq(dev);
which calls:
pm_runtime_mark_last_busy(dev);
pm_request_resume(dev);
and aside of that tells the device via a flag or preferrably a
sequence counter that the wakeup irq has been triggered. So affected
devices can handle it based on that information w/o implementing the
next broken variant of wakeup irq handlers.
That also allows to remove the wakeflags check for level/edge.
+ */
+int init_disabled_wakeirq(struct device *dev, unsigned int wakeirq,
+ unsigned long wakeflags)
+{
+ if (!(dev wakeirq)) {
This is the second time I stumbled over this. While it is correct it
would be simpler to parse
if (!dev || !wakeirq) {
At least for my review damaged brain :)
+ pr_err(Missing device or wakeirq for %s irq %d\n,
+dev_name(dev), wakeirq);
+ return -EINVAL;
+ }
+
+ if (!(wakeflags IRQF_ONESHOT)) {
+ pr_err(Invalid wakeirq for %s irq %d, must be oneshot\n,
+dev_name(dev), wakeirq);
+ return -EINVAL;
+ }
Is there a reason why we force the wakeirq into a threaded handler?
Thanks,
tglx
--
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] ARM: OMAP2+: some clock/hwmod patches for v3.19
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1: Linux 3.18-rc1 (2014-10-19 18:08:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.19/omap-a for you to fetch changes up to 79005fbd3e1d671d08c45c9140ee9826efdc367c: ARM: OMAP2+: hwmod: drop unnecessary list initialization (2014-11-13 09:36:55 -0700) - Some OMAP clock/hwmod patches for v3.19. Most of the patches are clock-related. The DPLL implementation is changed to better align to the common clock framework. There is also a patch that removes a few lines from the hwmod code - this patch should have no functional effect. Basic build, boot, and PM test logs for these patches can be found here: http://www.pwsan.com/omap/testlogs/omap-a-for-v3.19/20141113094101/ - Felipe Balbi (1): ARM: OMAP2+: hwmod: drop unnecessary list initialization Tero Kristo (5): ARM: OMAP3: clock: use clk_features flags for omap3 DPLL4 checks ARM: OMAP3: clock: add new rate changing logic support for noncore DPLLs ARM: OMAP4: clock: add support for determine_rate for omap4 regm4xen DPLL ARM: OMAP3: clock: add support for dpll4_set_rate_and_parent ARM: OMAP3+: DPLL: use determine_rate() and set_rate_and_parent() arch/arm/mach-omap2/cclock3xxx_data.c | 6 ++ arch/arm/mach-omap2/clock.c | 4 + arch/arm/mach-omap2/clock.h | 1 + arch/arm/mach-omap2/clock3xxx.c | 38 +++- arch/arm/mach-omap2/dpll3xxx.c| 179 ++ arch/arm/mach-omap2/dpll44xx.c| 41 arch/arm/mach-omap2/omap_hwmod.c | 2 - drivers/clk/ti/dpll.c | 15 +++ include/linux/clk/ti.h| 15 +++ 9 files changed, 238 insertions(+), 63 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUZTVVAAoJEMePsQ0LvSpL2pYP/ikYjpFzR0WpR/JHRwmCIe5X AgagOfimnSTqDKcLhnBgsVPfwxHHW+Uy6ubFGLOKGyKmVooQnfKL9nn6YXRfRi65 XuPmHLu9xdHwLsgBtiX2KSzLCmh6wqOqTDtYedwj8B0U8BsNpYVs01YchtJ4uR4p XpExYB6X6KvIl2PM14KoH35af6ZMkfnDXrLDtgBQ9KKea7e8U3SsZaTvnAZwu9W/ GxSijMsStWC03oa+1Q4hpwJXYIuPbRolhDwwIu2NslO018J5zmShNZQ5HpzKZ6Fh +Hh2aVE7z1BWTF+6KUVmmdBTNXpvnaKhktoGiZHLYB+r8HpFX2XG+Qd1F21UaKut TxaKSCdUDUxz/tDjE1wKDc0L4qYPC4eK9vgznOMudRMRSWV74dQQWyYIcXB/Wgk+ zQtSeBWxZN9c+xU+92gjb9HvSA8WKXeuW0RugbKTykySXSSPNi2emf3tzDoULNHL NZwYEKB197hk5ZvDmitN2t05R2EbUaC6eCTGxXFOkmYbbYaUFgvLsPzE8M+osKAb 1NcZC7eOH+9dF7afcn/C/b4a4B8D8A2PLl/QQ7P6sX/6++s3ec9aRAkVK+pp1zrW Dp+7J/T3zXqERjebT2vs3gQr0aaaT5N7HpScNkCAJaO+xiTirGHj6+YvVPqjD5kx sUlvR5n7z6SKRWMcuxIS =FxGb -END PGP SIGNATURE- -- 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 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
Hi On Thu, 13 Nov 2014, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [141113 03:33]: On 12/11/14 17:02, Tony Lindgren wrote: And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple places in the kernel. I wonder if adding a pinmux entry for it could cause some rather odd problems. They can all use pinctrl-single no problem. Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux, and we have code in mach-omap2 that also touch DEVCONF1, without any knowledge (and locking) between those... Hmm yeah the McBSP clock mux could be racy as the mux register for McBSP is treated as a clock. This register muxes the clock between external pin and internal clock. Considering that this should be selectable at board level as the external clock probably needs to be used if level shifters are being used, it should be really handled by pinctrl-single. The other use for hsmmc.c and pdata-quirks.c for the one time mux for MMC clock from the MMC clock pin. That can be done with pinctrl-single from the MMC driver too for DT based booting. Then we just have the save and restore of the registers for off-idle. So _maybe_ that's not an issue, as the pinmux config we have here is fixed, and done once at boot time, and maybe the code in mach-omap2 that touch DEVCONF1 is also ran just once and not at the same time as the pinmux. But I don't know if that's so. It seems we could just do a read-only check for McBSP in the clock code for the mux register, or even completely drop that code from cclock3xxx_data.c and start using the pinctrl for that mux. Paul Tero, got any comments here? It's best to move all of the SCM register reads/writes to an SCM IP block driver. This driver would be the only entity that would touch the SCM IP block registers - no other code on the system would touch it (perhaps aside from anything needed for early init). The SCM driver would enforce mutual exclusion via a spinlock, so concurrent SCM register modifications wouldn't flake out. Then the SCM driver would register clocks with the CCF, register pins with the pinctrl subsystem, etc. etc. - Paul -- 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 V3 3/3] mfd: palmas: Add support for optional wakeup
* Thomas Gleixner t...@linutronix.de [141113 14:27]:
On Thu, 13 Nov 2014, Tony Lindgren wrote:
Oops thanks for catching that. As the devres stuff is separate, I've
updated the patch to keep it that way by adding a minimal manage.h.
This avoids including internals.h in devres.c. Does that seem usable
for you?
What's wrong with internals.h? devres.c is core code, so it is not
affected of the ban to include internals.h :)
No problem, just that we need to bring in few other includes and
devres.c is currently free of any core irq stuff :) I can switch to
internals.h no problem if you prefer that.
+ * So if replaying the lost device interrupts is absolutely needed from the
+ * hardware point of view, it's probably best to set up a completely
+ * separate wake-up interrupt handler for the wake-up interrupt in the
+ * device driver because of the reasons above.
Can we please kill this last paragraph? I'm already seeing the
gazillion of I think it is required to do so for my s special
chip implementations in random drivers which all get it wrong again.
OK :)
So I'd rather provide a mechanism upfront which lets the driver know
that the wakeup interrupt originated from that device, i.e. let the
wake up handler call
pm_wakeup_irq(dev);
which calls:
pm_runtime_mark_last_busy(dev);
pm_request_resume(dev);
and aside of that tells the device via a flag or preferrably a
sequence counter that the wakeup irq has been triggered. So affected
devices can handle it based on that information w/o implementing the
next broken variant of wakeup irq handlers.
OK I'll take a look if we can just set some pm_runtime flag and use
the pm_runtime counters for that.
That also allows to remove the wakeflags check for level/edge.
+ */
+int init_disabled_wakeirq(struct device *dev, unsigned int wakeirq,
+ unsigned long wakeflags)
+{
+ if (!(dev wakeirq)) {
This is the second time I stumbled over this. While it is correct it
would be simpler to parse
if (!dev || !wakeirq) {
At least for my review damaged brain :)
Heh !!true.
+ pr_err(Missing device or wakeirq for %s irq %d\n,
+ dev_name(dev), wakeirq);
+ return -EINVAL;
+ }
+
+ if (!(wakeflags IRQF_ONESHOT)) {
+ pr_err(Invalid wakeirq for %s irq %d, must be oneshot\n,
+ dev_name(dev), wakeirq);
+ return -EINVAL;
+ }
Is there a reason why we force the wakeirq into a threaded handler?
Yes the drivers may need to restore hardware state in the pm_runtime
calls and who knows what else drivers will be doing. So that too might
be a good reason to just set a flag in pm_runtime land.
Anyways, thanks for your comments. I'll post a complete series after
looking into the wake-up counters a bit.
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 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
* Paul Walmsley p...@pwsan.com [141113 15:01]: Hi On Thu, 13 Nov 2014, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [141113 03:33]: On 12/11/14 17:02, Tony Lindgren wrote: And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple places in the kernel. I wonder if adding a pinmux entry for it could cause some rather odd problems. They can all use pinctrl-single no problem. Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux, and we have code in mach-omap2 that also touch DEVCONF1, without any knowledge (and locking) between those... Hmm yeah the McBSP clock mux could be racy as the mux register for McBSP is treated as a clock. This register muxes the clock between external pin and internal clock. Considering that this should be selectable at board level as the external clock probably needs to be used if level shifters are being used, it should be really handled by pinctrl-single. The other use for hsmmc.c and pdata-quirks.c for the one time mux for MMC clock from the MMC clock pin. That can be done with pinctrl-single from the MMC driver too for DT based booting. Then we just have the save and restore of the registers for off-idle. So _maybe_ that's not an issue, as the pinmux config we have here is fixed, and done once at boot time, and maybe the code in mach-omap2 that touch DEVCONF1 is also ran just once and not at the same time as the pinmux. But I don't know if that's so. It seems we could just do a read-only check for McBSP in the clock code for the mux register, or even completely drop that code from cclock3xxx_data.c and start using the pinctrl for that mux. Paul Tero, got any comments here? It's best to move all of the SCM register reads/writes to an SCM IP block driver. This driver would be the only entity that would touch the SCM IP block registers - no other code on the system would touch it (perhaps aside from anything needed for early init). The SCM driver would enforce mutual exclusion via a spinlock, so concurrent SCM register modifications wouldn't flake out. Then the SCM driver would register clocks with the CCF, register pins with the pinctrl subsystem, etc. etc. We actually do have that with pinctrl-single + syscon. We certainly need to implement more Linux framework drivers for the SCM registers. Things like regulators, clocks, and PHYs, but they should use pinctrl-single + syscon. See the the pbias-regulator.c for example. Looking at the McBSP clock handling, threre's yet more handling of the same DEVCONF1 mux register in omap2_mcbsp_set_clks_src that gets alled from omap_mcbsp_dai_set_dai_sysclk. To me it seems that if we handle the DEVCONF with pinctrl-single, we don't need most of the McBSP fck code or the omap2_mcbsp_set_clks_src. Having the mux register as the clock enable register is not nice.. Who knows what the clock coming from the external pin might be :) 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 0/3] Add support for ADC on am437x-gp and am43x-epos-evm
On Tuesday 04 November 2014 04:45 PM, Vignesh R wrote: This series of patches enable ADC on am437x-gp-evm and am43x-epos-evm. The ADC clock hwmod data of am33xx has been moved to commom place so that both am43xx and am33xx can reuse them. tscadc DT node has been adided to am437x-gp and am43x-epos dt files. With these patches, ADC functionalities are now available on am43xx. Changelog: v2: Removed phy addresses in hwmod. Using DT instead. Removed unused ti,am4372 compatible string. Use macro to set clk domain name. Fixed subject format of all patches Please accept these patches. Regards Vignesh R Vignesh R (3): ARM: OMAP2+: hwmod: AM335x/AM43x: Move am33xx_l4_hs_hwmod to ipblock_data ARM: OMAP2+: hwmod: AM335x/AM43x: add hwmod support for tscadc on am43x-evm ARM: dts: AM43xx: add tscadc DT entries for am437x-evm and am43x-epos-evm arch/arm/boot/dts/am4372.dtsi | 20 ++ arch/arm/boot/dts/am437x-gp-evm.dts| 8 +++ arch/arm/boot/dts/am43x-epos-evm.dts | 8 +++ .../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 2 + .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 71 ++ arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 64 --- arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 + 7 files changed, 110 insertions(+), 64 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
[PATCH v4 1/6] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps
From: Brad Griffis bgrif...@ti.com
This patch makes the initial changes required to workaround TSC-false
pen-up interrupts. It is required to implement these changes in order to
remove udelay in the TSC interrupt handler and false pen-up events.
The charge step is to be executed immediately after sampling X+. Hence
TSC is made to use higher numbered steps (steps 5 to 16 for 5 co-ordinate
readouts, 4 wire TSC configuration) and ADC to use lower ones. Further
X co-ordinate readouts must be the last to be sampled, thus co-ordinates
are sampled in the order Y-Z-X.
Signed-off-by: Brad Griffis bgrif...@ti.com
[vigne...@ti.com: Ported the patch from v3.12 to v3.18rc2]
Signed-off-by: Vignesh R vigne...@ti.com
Acked-by: Jonathan Cameron ji...@kernel.org
---
drivers/iio/adc/ti_am335x_adc.c | 5 ++--
drivers/input/touchscreen/ti_am335x_tsc.c | 42 ++-
2 files changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index b730864731e8..adba23246474 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -86,19 +86,18 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
{
struct tiadc_device *adc_dev = iio_priv(indio_dev);
unsigned int stepconfig;
- int i, steps;
+ int i, steps = 0;
/*
* There are 16 configurable steps and 8 analog input
* lines available which are shared between Touchscreen and ADC.
*
-* Steps backwards i.e. from 16 towards 0 are used by ADC
+* Steps forwards i.e. from 0 towards 16 are used by ADC
* depending on number of input lines needed.
* Channel would represent which analog input
* needs to be given to ADC to digitalize data.
*/
- steps = TOTAL_STEPS - adc_dev-channels;
if (iio_buffer_enabled(indio_dev))
stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1
| STEPCONFIG_MODE_SWCNT;
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 2ce649520fe0..1aeac9675fe7 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -121,7 +121,7 @@ static void titsc_step_config(struct titsc *ts_dev)
{
unsigned intconfig;
int i;
- int end_step;
+ int end_step, first_step, tsc_steps;
u32 stepenable;
config = STEPCONFIG_MODE_HWSYNC |
@@ -140,9 +140,11 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
}
- /* 1 … coordinate_readouts is for X */
- end_step = ts_dev-coordinate_readouts;
- for (i = 0; i end_step; i++) {
+ tsc_steps = ts_dev-coordinate_readouts * 2 + 2;
+ first_step = TOTAL_STEPS - tsc_steps;
+ /* Steps 16 to 16-coordinate_readouts is for X */
+ end_step = first_step + tsc_steps;
+ for (i = end_step - ts_dev-coordinate_readouts; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
@@ -164,9 +166,9 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
}
- /* coordinate_readouts … coordinate_readouts * 2 is for Y */
- end_step = ts_dev-coordinate_readouts * 2;
- for (i = ts_dev-coordinate_readouts; i end_step; i++) {
+ /* 1 ... coordinate_readouts is for Y */
+ end_step = first_step + ts_dev-coordinate_readouts;
+ for (i = first_step; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
@@ -179,7 +181,7 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
- /* coordinate_readouts * 2 … coordinate_readouts * 2 + 2 is for Z */
+ /* coordinate_readouts + 1 ... coordinate_readouts + 2 is for Z */
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | ts_dev-bit_yp |
ts_dev-bit_xn | STEPCONFIG_INM_ADCREFM |
@@ -194,8 +196,11 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
STEPCONFIG_OPENDLY);
- /* The steps1 … end and bit 0 for TS_Charge */
- stepenable = (1 (end_step + 2)) - 1;
+ /* The steps end ... end - readouts * 2 + 2 and bit 0 for TS_Charge */
+ stepenable = 1;
+ for (i = 0; i tsc_steps; i++)
+ stepenable |= 1 (first_step + i + 1);
+
ts_dev-step_mask = stepenable;
am335x_tsc_se_set_cache(ts_dev-mfd_tscadc, ts_dev-step_mask);
}
@@ -209,6 +214,7 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
[PATCH v4 4/6] ARM: dts: AM335x: Make charge delay a DT parameter for TSC
The charge delay value is by default 0x400. But it can be set to lower
values on some boards, as long as false pen-ups are avoided. Lowering the
value increases the sampling rate (though current sampling rate is
sufficient for TSC operation). In some boards, the value has to be
increased to avoid false pen-up events. Hence, charge delay has been
made a DT parameter.
Signed-off-by: Vignesh R vigne...@ti.com
---
v4:
- Set charge delay to 0x400 as default. Most devices function normally
at this value
.../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 15 +++
arch/arm/boot/dts/am335x-evm.dts | 1 +
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
index 878549ba814d..6df5028a4ad3 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -28,6 +28,20 @@ Required properties:
ti,adc-channels: List of analog inputs available for ADC.
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
+Optional properties:
+- child tsc
+ ti,charge-delay: Length of touch screen charge delay step in terms of
+ADC clock cycles. Charge delay value should be large
+in order to avoid false pen-up events. This value
+affects the overall sampling speed, hence need to be
+kept as low as possible, while avoiding false pen-up
+event. Start from a lower value, say 0x400, and
+increase value until false pen-up events are avoided.
+The pen-up detection happens immediately after the
+charge step, so this does in fact function as a
+hardware knob for adjusting the amount of settling
+time.
+
Example:
tscadc: tscadc@44e0d000 {
compatible = ti,am3359-tscadc;
@@ -36,6 +50,7 @@ Example:
ti,x-plate-resistance = 200;
ti,coordiante-readouts = 5;
ti,wire-config = 0x00 0x11 0x22 0x33;
+ ti,charge-delay = 0x400;
};
adc {
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e2156a583de7..ce12f6ef1e28 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -641,6 +641,7 @@
ti,x-plate-resistance = 200;
ti,coordinate-readouts = 5;
ti,wire-config = 0x00 0x11 0x22 0x33;
+ ti,charge-delay = 0x400;
};
adc {
--
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 v4 5/6] input: touchscreen: ti_am335x_tsc: Use charge delay DT parameter
This patch reads charge delay from tsc DT node and writes to
REG_CHARGEDELAY register. If the charge delay is not specified in DT
then default value of 0x400(CHARGEDLY_OPENDLY) is used.
Signed-off-by: Vignesh R vigne...@ti.com
---
drivers/input/touchscreen/ti_am335x_tsc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index b94719fc8849..e64055a8cd48 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -52,6 +52,7 @@ struct titsc {
u32 bit_xp, bit_xn, bit_yp, bit_yn;
u32 inp_xp, inp_xn, inp_yp, inp_yn;
u32 step_mask;
+ u32 charge_delay;
};
static unsigned int titsc_readl(struct titsc *ts, unsigned int reg)
@@ -177,7 +178,7 @@ static void titsc_step_config(struct titsc *ts_dev)
config = titsc_readl(ts_dev, REG_IDLECONFIG);
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
- titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
+ titsc_writel(ts_dev, REG_CHARGEDELAY, ts_dev-charge_delay);
/* coordinate_readouts + 1 ... coordinate_readouts + 2 is for Z */
config = STEPCONFIG_MODE_HWSYNC |
@@ -366,6 +367,11 @@ static int titsc_parse_dt(struct platform_device *pdev,
if (err 0)
return err;
+ err = of_property_read_u32(node, ti,charge-delay,
+ ts_dev-charge_delay);
+ if (err 0)
+ ts_dev-charge_delay = CHARGEDLY_OPENDLY;
+
return of_property_read_u32_array(node, ti,wire-config,
ts_dev-config_inp, ARRAY_SIZE(ts_dev-config_inp));
}
--
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 v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
In one shot mode, sequencer automatically disables all enabled steps at
the end of each cycle. (both ADC steps and TSC steps) Hence these steps
need not be saved in reg_se_cache for clearing these steps at a later
stage.
Also, when ADC wakes up Sequencer should not be busy executing any of the
config steps except for the charge step. Previously charge step was 1 ADC
clock cycle and hence it was ignored.
Signed-off-by: Vignesh R vigne...@ti.com
---
drivers/mfd/ti_am335x_tscadc.c | 7 +--
include/linux/mfd/ti_am335x_tscadc.h | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index d877e777cce6..110038859a8d 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -86,8 +86,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
*tsadc)
spin_lock_irq(tsadc-reg_lock);
finish_wait(tsadc-reg_se_wait, wait);
+ /*
+* Sequencer should either be idle or
+* busy applying the charge step.
+*/
reg = tscadc_readl(tsadc, REG_ADCFSM);
- WARN_ON(reg SEQ_STATUS);
+ WARN_ON((reg SEQ_STATUS) !(reg CHARGE_STEP));
tsadc-adc_waiting = false;
}
tsadc-adc_in_use = true;
@@ -96,7 +100,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
*tsadc)
void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
{
spin_lock_irq(tsadc-reg_lock);
- tsadc-reg_se_cache |= val;
am335x_tscadc_need_adc(tsadc);
tscadc_writel(tsadc, REG_SE, val);
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index 3f4e994ace2b..1fd50dcfe47c 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -128,6 +128,7 @@
/* Sequencer Status */
#define SEQ_STATUS BIT(5)
+#define CHARGE_STEP0x11
#define ADC_CLK300
#define TOTAL_STEPS16
--
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 v4 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
From: Brad Griffis bgrif...@ti.com
TSC interrupt handler had udelay to avoid reporting of false pen-up
interrupt to user space. This patch implements workaround suggesting in
Advisory 1.0.31 of silicon errata for am335x, thus eliminating udelay
and touchscreen lag. This also improves performance of touchscreen and
eliminates sudden jump of cursor at touch release.
IDLECONFIG and CHARGECONFIG registers are to be configured
with same values in order to eliminate false pen-up events. This
workaround may result in false pen-down to be detected, hence considerable
charge step delay needs to be added. The charge delay is set to 0xB000
(in terms of ADC clock cycles) by default.
TSC steps are disabled at the end of every sampling cycle and EOS bit is
set. Once the EOS bit is set, the TSC steps need to be re-enabled to begin
next sampling cycle.
Signed-off-by: Brad Griffis bgrif...@ti.com
[vigne...@ti.com: Ported the patch from v3.12 to v3.18rc2]
Signed-off-by: Vignesh R vigne...@ti.com
---
v4:
- check for PEN_IRQ bit in ADCFSM to avoid false-pen when ADC
and TSC are used together.
- Set charge delay to 0x400 as default. Most devices function
normally at this value.
drivers/input/touchscreen/ti_am335x_tsc.c | 63 ++-
include/linux/mfd/ti_am335x_tscadc.h | 3 +-
2 files changed, 30 insertions(+), 36 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 1aeac9675fe7..b94719fc8849 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -173,11 +173,9 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
- /* Charge step configuration */
- config = ts_dev-bit_xp | ts_dev-bit_yn |
- STEPCHARGE_RFP_XPUL | STEPCHARGE_RFM_XNUR |
- STEPCHARGE_INM_AN1 | STEPCHARGE_INP(ts_dev-inp_yp);
+ /* Make CHARGECONFIG same as IDLECONFIG */
+ config = titsc_readl(ts_dev, REG_IDLECONFIG);
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
@@ -261,12 +259,34 @@ static irqreturn_t titsc_irq(int irq, void *dev)
{
struct titsc *ts_dev = dev;
struct input_dev *input_dev = ts_dev-input;
- unsigned int status, irqclr = 0;
+ unsigned int fsm, status, irqclr = 0;
unsigned int x = 0, y = 0;
unsigned int z1, z2, z;
- unsigned int fsm;
- status = titsc_readl(ts_dev, REG_IRQSTATUS);
+ status = titsc_readl(ts_dev, REG_RAWIRQSTATUS);
+ if (status IRQENB_HW_PEN) {
+ ts_dev-pen_down = true;
+ titsc_writel(ts_dev, REG_IRQWAKEUP, 0x00);
+ titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
+ irqclr |= IRQENB_HW_PEN;
+ }
+
+ if (status IRQENB_PENUP) {
+ fsm = titsc_readl(ts_dev, REG_ADCFSM);
+ if (fsm == ADCFSM_STEPID) {
+ ts_dev-pen_down = false;
+ input_report_key(input_dev, BTN_TOUCH, 0);
+ input_report_abs(input_dev, ABS_PRESSURE, 0);
+ input_sync(input_dev);
+ } else {
+ ts_dev-pen_down = true;
+ }
+ irqclr |= IRQENB_PENUP;
+ }
+
+ if (status IRQENB_EOS)
+ irqclr |= IRQENB_EOS;
+
/*
* ADC and touchscreen share the IRQ line.
* FIFO1 interrupts are used by ADC. Handle FIFO0 IRQs here only
@@ -297,34 +317,6 @@ static irqreturn_t titsc_irq(int irq, void *dev)
}
irqclr |= IRQENB_FIFO0THRES;
}
-
- /*
-* Time for sequencer to settle, to read
-* correct state of the sequencer.
-*/
- udelay(SEQ_SETTLE);
-
- status = titsc_readl(ts_dev, REG_RAWIRQSTATUS);
- if (status IRQENB_PENUP) {
- /* Pen up event */
- fsm = titsc_readl(ts_dev, REG_ADCFSM);
- if (fsm == ADCFSM_STEPID) {
- ts_dev-pen_down = false;
- input_report_key(input_dev, BTN_TOUCH, 0);
- input_report_abs(input_dev, ABS_PRESSURE, 0);
- input_sync(input_dev);
- } else {
- ts_dev-pen_down = true;
- }
- irqclr |= IRQENB_PENUP;
- }
-
- if (status IRQENB_HW_PEN) {
-
- titsc_writel(ts_dev, REG_IRQWAKEUP, 0x00);
- titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
- }
-
if (irqclr) {
titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
am335x_tsc_se_set_cache(ts_dev-mfd_tscadc, ts_dev-step_mask);
@@ -417,6 +409,7 @@ static int titsc_probe(struct platform_device *pdev)
}
[PATCH v4 0/6] Touchscreen performance related fixes
This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement Advisory 1.0.31 in silicon errata of am335x-evm to avoid false pen-up events and remove udelay. The advisory says to use steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel ADC). Further the X co-ordinate must be the last one to be sampled just before charge step. The first two patches implement the required changes. A DT parameter to configure the duration of tsc charge step. It represents number of ADC clock cycles to wait between applying the step configuration registers and going back to the IDLE state. The charge delay value can vary across boards. Configuring correct value of charge delay is important to avoid false pen-up events. Hence it is necessary to expose charge-delay value as DT parameter. The pen-up detection happens immediately after the charge step so this does in fact function as a hardware knob for adjusting the amount of settling time. After applying these changes false pen-up events have not be observed and smooth circles can be drawn on touch screen. The performance is much better in recognizing quick movement across the screen. No lag or cursor jump is observed. Change log: v3: - Replace delta filtering logic in TSC driver with median filtering as suggested by Richard. - Addressed Lee Jones comments. v2: - Addressed comments by Hartmut Knaack - patch 2 was split into two as per Lee Jones comment Brad Griffis (2): input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler Vignesh R (4): mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save ARM: dts: AM335x: Make charge delay a DT parameter for TSC input: touchscreen: ti_am335x_tsc: Use charge delay DT parameter input: touchscreen: ti_am335x_tsc: Replace delta filtering with median filtering .../bindings/input/touchscreen/ti-tsc-adc.txt | 15 ++ arch/arm/boot/dts/am335x-evm.dts | 1 + drivers/iio/adc/ti_am335x_adc.c| 5 +- drivers/input/touchscreen/ti_am335x_tsc.c | 186 +++-- drivers/mfd/ti_am335x_tscadc.c | 7 +- include/linux/mfd/ti_am335x_tscadc.h | 4 +- 6 files changed, 127 insertions(+), 91 deletions(-) -- 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 v4 6/6] input: touchscreen: ti_am335x_tsc: Replace delta filtering with median filtering
Previously, delta filtering was applied TSC co-ordinate readouts before
reporting a single value to user space. This patch replaces delta filtering
with median filtering. Median filtering sorts co-ordinate readouts, drops min
and max values, and reports the average of remaining values. This method is
more sensible than delta filering. Median filtering is applied only if number
of readouts is greater than 3 else just average of co-ordinate readouts is
reported.
Signed-off-by: Vignesh R vigne...@ti.com
---
drivers/input/touchscreen/ti_am335x_tsc.c | 91 +--
1 file changed, 51 insertions(+), 40 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index e64055a8cd48..b84493fc8a78 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -26,6 +26,7 @@
#include linux/delay.h
#include linux/of.h
#include linux/of_device.h
+#include linux/sort.h
#include linux/mfd/ti_am335x_tscadc.h
@@ -204,56 +205,61 @@ static void titsc_step_config(struct titsc *ts_dev)
am335x_tsc_se_set_cache(ts_dev-mfd_tscadc, ts_dev-step_mask);
}
+static int titsc_cmp_coord(const void *a, const void *b)
+{
+ return *(int *)a - *(int *)b;
+}
+
static void titsc_read_coordinates(struct titsc *ts_dev,
u32 *x, u32 *y, u32 *z1, u32 *z2)
{
- unsigned int fifocount = titsc_readl(ts_dev, REG_FIFO0CNT);
- unsigned int prev_val_x = ~0, prev_val_y = ~0;
- unsigned int prev_diff_x = ~0, prev_diff_y = ~0;
- unsigned int read, diff;
- unsigned int i, channel;
+ unsigned int yvals[7], xvals[7];
+ unsigned int i, xsum = 0, ysum = 0;
unsigned int creads = ts_dev-coordinate_readouts;
- unsigned int first_step = TOTAL_STEPS - (creads * 2 + 2);
- *z1 = *z2 = 0;
- if (fifocount % (creads * 2 + 2))
- fifocount -= fifocount % (creads * 2 + 2);
- /*
-* Delta filter is used to remove large variations in sampled
-* values from ADC. The filter tries to predict where the next
-* coordinate could be. This is done by taking a previous
-* coordinate and subtracting it form current one. Further the
-* algorithm compares the difference with that of a present value,
-* if true the value is reported to the sub system.
-*/
- for (i = 0; i fifocount; i++) {
- read = titsc_readl(ts_dev, REG_FIFO0);
-
- channel = (read 0xf) 16;
- read = 0xfff;
- if (channel first_step + creads + 2) {
- diff = abs(read - prev_val_x);
- if (diff prev_diff_x) {
- prev_diff_x = diff;
- *x = read;
- }
- prev_val_x = read;
+ for (i = 0; i creads; i++) {
+ yvals[i] = titsc_readl(ts_dev, REG_FIFO0);
+ yvals[i] = 0xfff;
+ }
- } else if (channel == first_step + creads + 1) {
- *z1 = read;
+ *z1 = titsc_readl(ts_dev, REG_FIFO0);
+ *z1 = 0xfff;
+ *z2 = titsc_readl(ts_dev, REG_FIFO0);
+ *z2 = 0xfff;
- } else if (channel == first_step + creads + 2) {
- *z2 = read;
+ for (i = 0; i creads; i++) {
+ xvals[i] = titsc_readl(ts_dev, REG_FIFO0);
+ xvals[i] = 0xfff;
+ }
- } else if (channel first_step) {
- diff = abs(read - prev_val_y);
- if (diff prev_diff_y) {
- prev_diff_y = diff;
- *y = read;
- }
- prev_val_y = read;
+ /*
+* If co-ordinates readouts is less than 4 then
+* report the average. In case of 4 or more
+* readouts, sort the co-ordinate samples, drop
+* min and max values and report the average of
+* remaining values.
+*/
+ if (creads = 3) {
+ for (i = 0; i creads; i++) {
+ ysum += yvals[i];
+ xsum += xvals[i];
}
+ ysum /= creads;
+ xsum /= creads;
+ } else {
+ sort(yvals, creads, sizeof(unsigned int),
+titsc_cmp_coord, NULL);
+ sort(xvals, creads, sizeof(unsigned int),
+titsc_cmp_coord, NULL);
+ for (i = 1; i creads - 1; i++) {
+ ysum += yvals[i];
+ xsum += xvals[i];
+ }
+ ysum /= creads - 2;
+ xsum /= creads - 2;
}
+ *y = ysum;
+ *x = xsum;
}
static irqreturn_t titsc_irq(int irq, void *dev)
@@ -367,6 +373,11 @@ static int titsc_parse_dt(struct platform_device *pdev,
Re: [PATCH v5 0/7] Per-user clock constraints
On 31 October 2014 12:33, Peter De Schrijver pdeschrij...@nvidia.com wrote: On Thu, Oct 30, 2014 at 11:48:26AM +0100, Tomeu Vizoso wrote: Hello, this fifth version of the series has just one change, suggested by Stephen: Hi Mike, how is this looking for 3.19? Regards, Tomeu * Initialize clk.ceiling_constraint to ULONG_MAX and warn about new floor constraints being higher than the existing ceiling. The first five patches are just cleanups that should be desirable on their own, and that should make easier to review the actual per-user clock patch. The sixth patch actually moves the per-clock data that was stored in struct clk to a new struct clk_core and adds references to it from both struct clk and struct clk_hw. struct clk is now ready to contain information that is specific to a given clk consumer. The seventh patch adds API for setting floor and ceiling constraints and stores that information on the per-user struct clk, which is iterable from struct clk_core. They are based on top of 3.18-rc1. http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=per-user-clk-constraints-v5 Acked-By: Peter De Schrijver pdeschrij...@nvidia.com Mike, Do you think this will be merged for 3.19? Thanks, Peter. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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: N900 modem support in 3.18-rc1
On 13.11.2014 18:24, Pavel Machek wrote: On Fri 2014-11-07 09:04:52, Ivaylo Dimitrov wrote: Sebastian is quiet, can we have the patch? :-). Sure, why not :) https://gitorious.org/linux-n900/freemangordons-linux-n900/commits/30e9a5c498a89cea4c29523f69e436bf0af3c631 commits 89ce13b, b81d80d, ec4d0dc, 91256e2 and 8022a6d - e29f558 (no idea why gitorious shows those mixed with SGX stuff, on my local tree it is contiguous patch series) didn't test against the current upstream, but I see no reason why those should not apply, build and run. About the pulseaudio stuff - we're still in process of REing it, so far there are 2 out of 3 closed Nokia modules ready (https://gitorious.org/pulseaudio-nokia), but the last one, which is the one used for voice calls is still not ready and will take it a while :). Ok, is there a way I could help? Pretty much everything else works with opensource drivers... There is, though I am not sure you'll like it much - fire up IDA and join the party :P. Ping me on IRC for more details in case you're interested. Regards, Ivo -- 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 6/7] clk: Make clk API return per-user struct clk instances
On 10/30, Tomeu Vizoso wrote: Moves clock state to struct clk_core, but takes care to change as little API as possible. struct clk_hw still has a pointer to a struct clk, which is the implementation's per-user clk instance, for backwards compatibility. The struct clk that clk_get_parent() returns isn't owned by the caller, but by the clock implementation, so the former shouldn't call clk_put() on it. Because some boards in mach-omap2 still register clocks statically, their clock registration had to be updated to take into account that the clock information is stored in struct clk_core now. Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com It would be good to have Russell at least ack the clkdev bits. There's still more work to do in the future here, but Reviewed-by: Stephen Boyd sb...@codeaurora.org -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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: [PATCHv6 4/5] hwspinlock/core: add common OF helpers
Hi Suman,
On Thu, Nov 13, 2014 at 11:02 PM, Suman Anna s-a...@ti.com wrote:
OK, lets take an example. I have say 2 device instances, say
hwlock1: hwlock@0 {
hwlock-num-locks = 32
hwlock-base-id = 0;
#hwlock-cells = 1;
};
hwlock2: hwlock@0 {
hwlock-num-locks = 32
hwlock-base-id = 32;
#hwlock-cells = 1;
};
some-client {
hwlocks = hwlock1 32, hwlock2 0;
};
The first args value is incorrect, and I expect the API to return an
error. I don't think the API can make assumptions that all passed in
values will be correct. What do you suggest that the API do here?
I think this is just one example of many potential mistakes the DT
developer can have, and that there's nothing really special about it.
What if the '5' digit below is a typo, and the actual hardware
assignment was supposed to be '4' ?
some-client {
hwlocks = hwlock1 5, hwlock2 5;
};
I don't see how much different this mistake is from the one you
mentioned above. There's a limit to how much we can really catch DT
mistakes in the code, just like we couldn't really catch past mistakes
in the platform data structures.
If we can easily add some validations then great, but if we have to go
to great lengths just to gain very limited validations, then I'd vote
against doing so.
One solution to handle #1 is to also make the hwlock-num-locks property
also mandatory (even though it could have been read from a register
Yeah, this is awkward. We shouldn't impose this on implementations
like OMAP which don't need it.
Again I think for the very limited validation this buys us - it's not worth it.
And, how do you propose we solve the problem of deferred probing?
It seems to me that hwspin_lock_request_specific failures should be
used by clients to defer their probing. Why wouldn't such a simple
solution work?
Thanks,
Ohad.
--
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 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
On 11/14/2014 01:58 AM, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [141113 15:01]: Hi On Thu, 13 Nov 2014, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [141113 03:33]: On 12/11/14 17:02, Tony Lindgren wrote: And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple places in the kernel. I wonder if adding a pinmux entry for it could cause some rather odd problems. They can all use pinctrl-single no problem. Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux, and we have code in mach-omap2 that also touch DEVCONF1, without any knowledge (and locking) between those... Hmm yeah the McBSP clock mux could be racy as the mux register for McBSP is treated as a clock. This register muxes the clock between external pin and internal clock. Considering that this should be selectable at board level as the external clock probably needs to be used if level shifters are being used, it should be really handled by pinctrl-single. The other use for hsmmc.c and pdata-quirks.c for the one time mux for MMC clock from the MMC clock pin. That can be done with pinctrl-single from the MMC driver too for DT based booting. Then we just have the save and restore of the registers for off-idle. So _maybe_ that's not an issue, as the pinmux config we have here is fixed, and done once at boot time, and maybe the code in mach-omap2 that touch DEVCONF1 is also ran just once and not at the same time as the pinmux. But I don't know if that's so. It seems we could just do a read-only check for McBSP in the clock code for the mux register, or even completely drop that code from cclock3xxx_data.c and start using the pinctrl for that mux. Paul Tero, got any comments here? It's best to move all of the SCM register reads/writes to an SCM IP block driver. This driver would be the only entity that would touch the SCM IP block registers - no other code on the system would touch it (perhaps aside from anything needed for early init). The SCM driver would enforce mutual exclusion via a spinlock, so concurrent SCM register modifications wouldn't flake out. Then the SCM driver would register clocks with the CCF, register pins with the pinctrl subsystem, etc. etc. We actually do have that with pinctrl-single + syscon. We certainly need to implement more Linux framework drivers for the SCM registers. Things like regulators, clocks, and PHYs, but they should use pinctrl-single + syscon. See the the pbias-regulator.c for example. Looking at the McBSP clock handling, threre's yet more handling of the same DEVCONF1 mux register in omap2_mcbsp_set_clks_src that gets alled from omap_mcbsp_dai_set_dai_sysclk. To me it seems that if we handle the DEVCONF with pinctrl-single, we don't need most of the McBSP fck code or the omap2_mcbsp_set_clks_src. Having the mux register as the clock enable register is not nice.. Who knows what the clock coming from the external pin might be :) The PRCM/clock cleanups that I have under work basically splits the clock inits under their respective IP blocks; currently everything is registered under generic PRCM. System control module will be one of the clock providers (and is going to look like a driver), which will be registering its own clocks. This doesn't change the fact that pinctrl is directly mapping its own register space atm though, it might be possible to re-route this to use the generic system control module if need be though. I guess its just a political decision which way we want to go, currently we have lots of system control clocks under the clock data (for AM33xx,AM43xx,OMAP3), but we can remove these easily if need be. In some cases it is nicer to have the data in the clock tree though, the drivers don't need to care if they are touching a clock or a pinctrl entity. Some people have been converting additional stuff to CCF outside of PRCM, like Archit did some work to try and get control module clock support for DRA7, and Tomi has been talking to convert some of the DSS internal clocks to CCF also. -Tero -- 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: N900 modem support in 3.18-rc1
Hi! Do you have an example client that can talk to ofonod? I have not yet played with userland stuff. You could try telepathy-ring, which integrates the ofono into the telepathy framework. Ok, I took a look, and telepathy-ring is not in debian, and has a lot of dependencies. OTOH ofono seems pretty reasonable. So I played a bit, and result is python/pygtk gui which can receive an sms, initiate a call, and report missed call. If someone wants to play, source is at https://gitorious.org/tui/tui/source/b6141107e9341a1412720aed4b0d09143dfa2f4e:ofone Pavel, care to fill in the the following type patch with some instructions in the description now that you got it working? I did not have luck yet when I tried. I got the /dev/cmt/* entries after adding pm=1 param, but no luck scanning any networks. I'm using nfsroot (no modules), .config is attached. Debian v7.7, ofono installed. To launch ofono, I'm using: rmdir /dev/cmt ln -s /sys/bus/hsi/devices/n900-modem/ /dev/cmt killall ofonod sleep .1 ofonod --nodetach --debug # enable the modem mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Powered true # enable modem's RF parts mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Online true # scan for available networks (takes some time) mdbus2 -s org.ofono /n900_0 org.ofono.NetworkRegistration.Scan I do have working SIM card in it. (Alternatively, ofone button online can be used). Good luck, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html # # Automatically generated file; DO NOT EDIT. # Linux/arm 3.18.0-rc1 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_ARM_DMA_USE_IOMMU=y CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8 CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION=-omap3 CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set CONFIG_KERNEL_LZMA=y # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_CROSS_MEMORY_ATTACH is not set # CONFIG_FHANDLE is not set CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_HANDLE_DOMAIN_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_PREEMPT_RCU=y CONFIG_PREEMPT_RCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_BOOST is not set # CONFIG_RCU_NOCB_CPU is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=20 CONFIG_GENERIC_SCHED_CLOCK=y # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_EXPERT=y CONFIG_UID16=y # CONFIG_SGETMASK_SYSCALL is not set CONFIG_SYSFS_SYSCALL=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y
