Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
On Thursday 10 October 2013 07:49 PM, Nishanth Menon wrote:
On 16:19-20131010, Kishon Vijay Abraham I wrote:
smps10 should be enabled only in the case of host mode. So stop
doing always_on, boot_on from smps10_out1. The driver will enable it in host
mode.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index d784b3a..e06a04a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -334,8 +334,6 @@
regulator-name = smps10_out1;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
-regulator-always-on;
-regulator-boot-on;
};
ldo1_reg: ldo1 {
--
Always good to get rid of regulator-always-on. Thanks for it.
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP information - regulator-boot-on should be kept here.
No. Actually I don’t want PMIC to enable it by default. I want the palmas-usb
driver to handle it.
Enabling it by default makes palmas-usb to detect VBUS interrupt. This should
ideally be detected only when you connect a host cable.
Btw I didn't exactly get why you want regulator-boot-on should be kept here.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP information - regulator-boot-on should be kept here.
No. Actually I don’t want PMIC to enable it by default. I want the palmas-usb
driver to handle it.
Enabling it by default makes palmas-usb to detect VBUS interrupt. This should
ideally be detected only when you connect a host cable.
Btw I didn't exactly get why you want regulator-boot-on should be kept here.
binding description states:
- regulator-boot-on: bootloader/firmware enabled regulator
Further info: include/linux/regulator/machine.h
* @boot_on: Set if the regulator is enabled when the system is initially
* started. If the regulator is not enabled by the hardware or
* bootloader then it will be enabled when the constraints are
* applied.
What that means is that it is enabled by firmware/bootloader (in our
case One Time Program {OTP} inside Palmas) when the system switches on
even before the kernel starts. and we know SMPS10 is autoenabled by
Palmas OTP configuration even before first instruction in A15
executes.
I think you misunderstand this to mean that you'd like the regulator
to be *switched on* automatically at kernel boot by regulator
framework - there is no reasoning why we'd want such a binding since
we'd expect drivers to do their job of requesting and enabling
regulators on need..
Hope this helps. Let me know if I misunderstood something here.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
Hi,
On Friday 11 October 2013 12:00 PM, Nishanth Menon wrote:
On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP information - regulator-boot-on should be kept here.
No. Actually I don’t want PMIC to enable it by default. I want the palmas-usb
driver to handle it.
Enabling it by default makes palmas-usb to detect VBUS interrupt. This should
ideally be detected only when you connect a host cable.
Btw I didn't exactly get why you want regulator-boot-on should be kept here.
binding description states:
- regulator-boot-on: bootloader/firmware enabled regulator
Further info: include/linux/regulator/machine.h
* @boot_on: Set if the regulator is enabled when the system is initially
* started. If the regulator is not enabled by the hardware or
* bootloader then it will be enabled when the constraints are
* applied.
What that means is that it is enabled by firmware/bootloader (in our
case One Time Program {OTP} inside Palmas) when the system switches on
even before the kernel starts. and we know SMPS10 is autoenabled by
Palmas OTP configuration even before first instruction in A15
executes.
Not sure about that. Please note SMPS10 has two outputs OUT1 and OUT2 and I
tend to think that it might be OUT2 that's getting enabled by the OTP.
I think you misunderstand this to mean that you'd like the regulator
to be *switched on* automatically at kernel boot by regulator
framework - there is no reasoning why we'd want such a binding since
we'd expect drivers to do their job of requesting and enabling
regulators on need..
The comment you just quoted tells it enables the regulator if its not enabled
by hardware. If the regulator is not enabled by the hardware or bootloader
then it will be enabled when the constraints are applied. At-least that's what
I understood from that comment.
Also from our experiments it doesn't look like SMPS10_OUT1 is enabled by the
OTP and it gets enabled when we have *regulator-boot-on* constraints.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
On Friday 11 October 2013 12:23 PM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 11 October 2013 12:00 PM, Nishanth Menon wrote:
On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP information - regulator-boot-on should be kept here.
No. Actually I don’t want PMIC to enable it by default. I want the
palmas-usb
driver to handle it.
Enabling it by default makes palmas-usb to detect VBUS interrupt. This
should
ideally be detected only when you connect a host cable.
Btw I didn't exactly get why you want regulator-boot-on should be kept here.
binding description states:
- regulator-boot-on: bootloader/firmware enabled regulator
Further info: include/linux/regulator/machine.h
* @boot_on: Set if the regulator is enabled when the system is initially
* started. If the regulator is not enabled by the hardware or
* bootloader then it will be enabled when the constraints are
* applied.
What that means is that it is enabled by firmware/bootloader (in our
case One Time Program {OTP} inside Palmas) when the system switches on
even before the kernel starts. and we know SMPS10 is autoenabled by
Palmas OTP configuration even before first instruction in A15
executes.
Not sure about that. Please note SMPS10 has two outputs OUT1 and OUT2 and I
tend to think that it might be OUT2 that's getting enabled by the OTP.
I think you misunderstand this to mean that you'd like the regulator
to be *switched on* automatically at kernel boot by regulator
framework - there is no reasoning why we'd want such a binding since
we'd expect drivers to do their job of requesting and enabling
regulators on need..
The comment you just quoted tells it enables the regulator if its not enabled
by hardware. If the regulator is not enabled by the hardware or bootloader
then it will be enabled when the constraints are applied. At-least that's
what
I understood from that comment.
Also from our experiments it doesn't look like SMPS10_OUT1 is enabled by the
OTP and it gets enabled when we have *regulator-boot-on* constraints.
btw.. I think this is the code in regulator fw that's responsible for enabling..
/* If the constraints say the regulator should be on at this point
* and we have control then make sure it is enabled.
*/
if ((rdev-constraints-always_on || rdev-constraints-boot_on)
ops-enable) {
ret = ops-enable(rdev);
if (ret 0) {
rdev_err(rdev, failed to enable\n);
goto out;
}
}
Thanks
Kishon
--
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] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
On 10/11/2013 06:41 AM, Tomi Valkeinen wrote: On 10/10/13 21:58, Lars-Peter Clausen wrote: According to the datasheet the the panel as a dedicated dout pin. Maybe you did not connect it in your design, which means you won't be able to read any data from the panel at all. I don't see a dedicated dout in the datasheet... http://dl.wolfgang-draxinger.net/openmoko/doc/TD028TTEC1.pdf Hm, ok, looks like the display controller used in the panel (the jbt6k74) has separate DIN and DOUT, but the panel only has one pin. But the datasheet for the panel is not exactly clear on whether it's DIN pin is both the DIN and DOUT pin from the controller or, just DIN and DOUT not being connected at all. Also your custom bitbang code looks a bit strange: gpio_set_value(data-dout_gpio, 1); if (gpio_get_value(data-din_gpio) == 0) return 1; You set the state on the dout pin and then read the din pin, if both do not match you abort with an error. This suggest that, for whatever reason, you feed the dout pin back into the din pin in your design. Btw. this is also the only place where din is used in your driver. Yes, he said the single Serial interface data input/output pin is connected to both din and dout on the SoC. I guess the purpose of that gpio_get_value() is to ensure that the panel is not pulling the line when the SoC is writing to it. Not that I really understand how that can work, but I'm not a HW guy =). Hm, ok. I don't think the panel will ever actively drive the line. So in my opinion using either the McBSP SPI master or the GPIO bitbang SPI master should work just fine. You just wouldn't be able to read any register from the device. But the driver is not attempting to do this, so it should be fine. - Lars -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap5-uevm: remove always_on, boot_on from smps10_out1
On Fri, Oct 11, 2013 at 1:54 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
On Friday 11 October 2013 12:23 PM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 11 October 2013 12:00 PM, Nishanth Menon wrote:
On Fri, Oct 11, 2013 at 1:13 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
regulator-boot-on indicates that PMIC enables it by default as part of
OTP or some internal behavior - Looking at the measurements done on
uEVM and OTP information - regulator-boot-on should be kept here.
No. Actually I don’t want PMIC to enable it by default. I want the
palmas-usb
driver to handle it.
Enabling it by default makes palmas-usb to detect VBUS interrupt. This
should
ideally be detected only when you connect a host cable.
Btw I didn't exactly get why you want regulator-boot-on should be kept
here.
binding description states:
- regulator-boot-on: bootloader/firmware enabled regulator
Further info: include/linux/regulator/machine.h
* @boot_on: Set if the regulator is enabled when the system is initially
* started. If the regulator is not enabled by the hardware or
* bootloader then it will be enabled when the constraints are
* applied.
What that means is that it is enabled by firmware/bootloader (in our
case One Time Program {OTP} inside Palmas) when the system switches on
even before the kernel starts. and we know SMPS10 is autoenabled by
Palmas OTP configuration even before first instruction in A15
executes.
Not sure about that. Please note SMPS10 has two outputs OUT1 and OUT2 and I
tend to think that it might be OUT2 that's getting enabled by the OTP.
I think you misunderstand this to mean that you'd like the regulator
to be *switched on* automatically at kernel boot by regulator
framework - there is no reasoning why we'd want such a binding since
we'd expect drivers to do their job of requesting and enabling
regulators on need..
The comment you just quoted tells it enables the regulator if its not enabled
by hardware. If the regulator is not enabled by the hardware or bootloader
then it will be enabled when the constraints are applied. At-least that's
what
I understood from that comment.
Also from our experiments it doesn't look like SMPS10_OUT1 is enabled by the
OTP and it gets enabled when we have *regulator-boot-on* constraints.
btw.. I think this is the code in regulator fw that's responsible for
enabling..
/* If the constraints say the regulator should be on at this point
* and we have control then make sure it is enabled.
*/
if ((rdev-constraints-always_on || rdev-constraints-boot_on)
ops-enable) {
ret = ops-enable(rdev);
if (ret 0) {
rdev_err(rdev, failed to enable\n);
goto out;
}
}
Drat, you are right, I did not really dig deep. thanks for correcting
my understanding here.
I propose the following change in binding as it seems completely
misleading to me.
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt
b/Documentation/devicetree/bindings/regulator/regulator.txt
index 2bd8f09..d999f096 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -8,7 +8,9 @@ Optional properties:
- regulator-min-microamp: smallest current consumers may set
- regulator-max-microamp: largest current consumers may set
- regulator-always-on: boolean, regulator should never be disabled
-- regulator-boot-on: bootloader/firmware enabled regulator
+- regulator-boot-on: regulator is enabled when the system is initially started.
+ If the regulator is not enabled by the hardware or bootloader then it will be
+ enabled when the constraints are applied.
- regulator-allow-bypass: allow the regulator to go into bypass mode
- name-supply: phandle to the parent supply/regulator node
- regulator-ramp-delay: ramp delay for regulator(in uV/uS)
--
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] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Hi all, Am 11.10.2013 um 06:41 schrieb Tomi Valkeinen: On 10/10/13 21:58, Lars-Peter Clausen wrote: According to the datasheet the the panel as a dedicated dout pin. Maybe you did not connect it in your design, which means you won't be able to read any data from the panel at all. I don't see a dedicated dout in the datasheet... http://dl.wolfgang-draxinger.net/openmoko/doc/TD028TTEC1.pdf Also your custom bitbang code looks a bit strange: gpio_set_value(data-dout_gpio, 1); if (gpio_get_value(data-din_gpio) == 0) return 1; You set the state on the dout pin and then read the din pin, if both do not match you abort with an error. This suggest that, for whatever reason, Detecting hardware failure. If the panel is not connected or broken (short circuit) reading back may fail and this can help to detect a hardware failure. you feed the dout pin back into the din pin in your design. Btw. this is also the only place where din is used in your driver. Ok, I see the issue with that. It assumes this type of feedback which does not necessarily exist. I.e. if someone else doesn't have this feedback line the driver will not work. So a more general solution should work with any setup, even if no din gpio has been defined. I.e. do this test only if the din_gpio exists. The main reason that we don't use din_gpio elsewhere is that we have no jbt_read() function because we lack information what we can read from the panel controller chip - and have not seen a use-case for that. And thanks to your hint, I think either returning 1 is wrong (should be some -EIO or similar). Or the return r; at the end of td028ttec1_panel_enable is wrong (should be return rc ? -EIO : 0; ). We will check that. Yes, he said the single Serial interface data input/output pin is connected to both din and dout on the SoC. I have found two public links which may describe what we do: The panel data sheet [1], Section 9 describes the interface as 3 wire serial interface. It sometimes calls the data lines DIN and DOUT and describes them separately, i.e. like a 4 wire interface. So I guess the jbt6k chip has indeed 4 wires, but (as you said), din/dout are lines are tied together on the panel side to save (share) one wire in the flex cable. [2] shows in figure 2 an example how to connect a 3-wire interface to a 4-wire SPI SoC. This is the way we have done it. I guess the purpose of that gpio_get_value() is to ensure that the panel is not pulling the line when the SoC is writing to it. Not that I really understand how that can work, but I'm not a HW guy =). Finally, I have checked one detail which rules out to use a standard SPI driver for OMAP on our board. The reason is that we have a McBSP port of the OMAP3 and not a McSPI. So we have to run this 3 wire serial interface protocol by bitbanging. IMHO, the most flexible way to hook up the panel (and driver) to arbitrary hardware is by using GPIOs and not having the panel driver restrict to a SPI interface. And having the bitbanging encapsulated in the driver itself (instead on relying on some spi-bitbang) makes it less dependent on changes somewhere else. I.e. the driver module is indeed a module. Marek is preparing an updated patch for further discussion. BR, Nikolaus [1]: http://dl.wolfgang-draxinger.net/openmoko/doc/TD028TTEC1.pdf [2]: http://www.totalphase.com/support/kb/10059/ -- 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] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Hi Lars-Peter, ah, I didn't see your mail while writing mine - so some overlap. Am 11.10.2013 um 09:08 schrieb Lars-Peter Clausen: On 10/11/2013 06:41 AM, Tomi Valkeinen wrote: On 10/10/13 21:58, Lars-Peter Clausen wrote: According to the datasheet the the panel as a dedicated dout pin. Maybe you did not connect it in your design, which means you won't be able to read any data from the panel at all. I don't see a dedicated dout in the datasheet... http://dl.wolfgang-draxinger.net/openmoko/doc/TD028TTEC1.pdf Hm, ok, looks like the display controller used in the panel (the jbt6k74) has separate DIN and DOUT, but the panel only has one pin. Yes But the datasheet for the panel is not exactly clear Yes on whether it's DIN pin is both the DIN and DOUT pin from the controller or, just DIN and DOUT not being connected at all. I think they have a 4-wire controller in the panel and tied the lines together. This works if they properly control the data direction. There are some read commands where this direction reversal happens. Also your custom bitbang code looks a bit strange: gpio_set_value(data-dout_gpio, 1); if (gpio_get_value(data-din_gpio) == 0) return 1; You set the state on the dout pin and then read the din pin, if both do not match you abort with an error. This suggest that, for whatever reason, you feed the dout pin back into the din pin in your design. Btw. this is also the only place where din is used in your driver. Yes, he said the single Serial interface data input/output pin is connected to both din and dout on the SoC. I guess the purpose of that gpio_get_value() is to ensure that the panel is not pulling the line when the SoC is writing to it. Not that I really understand how that can work, but I'm not a HW guy =). Hm, ok. I don't think the panel will ever actively drive the line. Well it will drive it if we issue some read command (but I have no information about these commands). So in my opinion using either the McBSP SPI master or the GPIO bitbang SPI master should work just fine. You just wouldn't be able to read any register from the device. But the driver is not attempting to do this, so it should be fine. I am not sure if there is a SPI driver for a McBSP port [1]? And to make that work (reliably) and tested it might need a lot of work for us. At least I think such a change (e.g. setting up clock polarity etc.) is not done in some minutes. And the only feedback we have from the panel is does not work/works. I.e. if we are not lucky that it works immediately we have no real means to debug. IMHO it also gives more flexibility to board designers to choose GPIOs instead of enforcing some SPI interface by the driver (and encapsulate this arguable protocol in the driver). Maybe some board has 3 spare GPIOs but neither McBSPs nor McSPIs available. BR, Nikolaus http://lists.infradead.org/pipermail/linux-arm-kernel/2011-June/053064.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 v5 3/4] v4l: ti-vpe: Add VPE mem to mem driver
On 10/09/2013 04:29 PM, Archit Taneja wrote: VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. When the list is parsed completely(and the DMAs on all the output ports done), an interrupt is generated which we use to notify that the source and destination buffers are done. The rest of the driver is quite similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as the HW support coplanar formats. Signed-off-by: Archit Taneja arc...@ti.com Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans -- 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/6] pinctrl: single: Add support for wake-up interrupts
On Thu, Oct 10, 2013 at 6:20 PM, Tony Lindgren t...@atomide.com wrote: * Linus Walleij linus.wall...@linaro.org [131010 09:19]: On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren t...@atomide.com wrote: * Roger Quadros rog...@ti.com [131010 06:32]: I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts while the system is still running and only the EHCI controller is runtime suspended. It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain whenever the pad wakeup_enable bit is changed. Sounds like this is on omap3? Have you tried calling pcs_soc-rearm() in the pcs_irq_handle() like the comments there suggest? At least for me that keeps the wake-up interrupts continuously running on omap3 instead of just idle modes. If the rearm() function is calling this _reconfigure_io_chain my comments on the fact that this is something that should be handled by the pin control driver still apply I think Yes, except that the reconfigure_io_chain registers are in the PRM module, not in the SCM module where the pinctrl registers are.. And that shared PRM interrupt is used mostly for the internal domain wake-ups, so we should keep that in the PRM driver. That depends. One-iorange-equals-one-driver is a fallacy, especially given that MFD for memory-mapped things exist for a reason. What the pin control driver should do is control the pins. Whether the registers are spread out in the entire IO-memory does not matter. We did have one system which placed the IO-muxing together with each peripheral (!) and I did still want that to be handled by a single pinctrl driver picking out windows to all these IO-ranges. Things like the PRM which has (my guess) a gazillion registers related to its deep-core SoC stuff should be handled by things like drivers/mfd/syscon.c, which means it is dead simple for some other driver using just this one register in that range to get a handle at it and poke it using syscon_node_to_regmap() (just derference an ampersand ref) syscon_regmap_lookup_by_compatible() (use a compatible string) all returning a regmap * that you can use to poke these registers. Yours, Linus Walleij -- 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] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote: I am not sure if there is a SPI driver for a McBSP port [1]? And to make that work (reliably) and tested it might need a lot of work for us. At least I think such a change (e.g. setting up clock polarity etc.) is not done in some minutes. And the only feedback we have from the panel is does not work/works. I.e. if we are not lucky that it works immediately we have no real means to debug. IMHO it also gives more flexibility to board designers to choose GPIOs instead of enforcing some SPI interface by the driver (and encapsulate this arguable protocol in the driver). Maybe some board has 3 spare GPIOs but neither McBSPs nor McSPIs available. This has been an interesting thread, I've learnt a lot =). I still think the panel driver should not handle this, but there should be a separate spi bitbang driver for it. I understand you're not enthusiastic going that way, as the current version works for you. However, when using DT, we need to think how to represent the hardware in the device tree data, and it has to be right from the beginning. That's why I won't allow representing this panel as having 4 gpios in the DT data, because that is not correct. The panel has 3 pins. But then, the panel does allow reading, which could be implemented using 4 gpios as you have done. This data should be in the spi-bitbang data, and the panel should just use the standard SPI framework. Using SPI framework does not mean you should use McBSP or McSPI. It's up to you how the 3-wire SPI is implemented on the SoC side, the panel would just work in all the cases. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
On 10/10/2013 07:23 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [131010 09:09]: * Roger Quadros rog...@ti.com [131010 06:32]: I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts while the system is still running and only the EHCI controller is runtime suspended. It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain whenever the pad wakeup_enable bit is changed. Sounds like this is on omap3? Have you tried calling pcs_soc-rearm() in the pcs_irq_handle() like the comments there suggest? At least for me that keeps the wake-up interrupts continuously running on omap3 instead of just idle modes. Now on omap4, I've noticed the wake up interrupts are on all the time based on tests with the serial driver. Oh, and if you're runtime suspending EHCI only, and if the EHCI module has wake-up registers, it should be able to wake EHCI from retention on it's own without a need for the io chain at all. The problem is that the asynchronous wake up mechanism for USB Host module is broken in the design so we have to rely on IO daisy chain every time. :( 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/6] pinctrl: single: Add support for wake-up interrupts
On 10/10/2013 07:00 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [131010 06:32]: I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts while the system is still running and only the EHCI controller is runtime suspended. It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain whenever the pad wakeup_enable bit is changed. Sounds like this is on omap3? Have you tried calling pcs_soc-rearm() in the pcs_irq_handle() like the comments there suggest? At least for me that keeps the wake-up interrupts continuously running on omap3 instead of just idle modes. Yes it is on OMAP3. I haven't tried with pcs_soc-rearm(). I will give it a try and let you know. Now on omap4, I've noticed the wake up interrupts are on all the time based on tests with the serial driver. I think pcs_irq_set_wake() is where need to control system wakeup behaviour for the irq. This is where we should be able to change WAKEUP_EN bit of the pad to enable/disable system wakeup for that pad and also call _reconfigure_io_chain(). Well the irq_set_wake() should only be needed for suspend and resume. For runtime PM the wake-events should be always enabled by default as pointed out by Alan Stern a while back. Right, but we need to update the WAKEUP_EN bit in the pad control register for that to work, no?. This is something we are not doing in the driver. This would mean that we don't really need to set WAKEUP_EN for the pads in the DTS file. Well for runtime PM, we should also do the automatic handling if configured. But how to do that best is still open.. I didn't get this part. I was thinking that irq_set_wake() should map directly to WAKEUP_EN bit for the pin. 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/6] pinctrl: single: Add support for wake-up interrupts
On 10/11/2013 11:00 AM, Linus Walleij wrote: On Thu, Oct 10, 2013 at 6:20 PM, Tony Lindgren t...@atomide.com wrote: * Linus Walleij linus.wall...@linaro.org [131010 09:19]: On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren t...@atomide.com wrote: * Roger Quadros rog...@ti.com [131010 06:32]: I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts while the system is still running and only the EHCI controller is runtime suspended. It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain whenever the pad wakeup_enable bit is changed. Sounds like this is on omap3? Have you tried calling pcs_soc-rearm() in the pcs_irq_handle() like the comments there suggest? At least for me that keeps the wake-up interrupts continuously running on omap3 instead of just idle modes. If the rearm() function is calling this _reconfigure_io_chain my comments on the fact that this is something that should be handled by the pin control driver still apply I think Yes, except that the reconfigure_io_chain registers are in the PRM module, not in the SCM module where the pinctrl registers are.. And that shared PRM interrupt is used mostly for the internal domain wake-ups, so we should keep that in the PRM driver. That depends. One-iorange-equals-one-driver is a fallacy, especially given that MFD for memory-mapped things exist for a reason. +1 Another place I faced a similar problem was the OMAP control module, which contains registers for a number of different non related peripherals. (e.g. PHY for USB, SATA, Display clock, etc) What the pin control driver should do is control the pins. Whether the registers are spread out in the entire IO-memory does not matter. We did have one system which placed the IO-muxing together with each peripheral (!) and I did still want that to be handled by a single pinctrl driver picking out windows to all these IO-ranges. Things like the PRM which has (my guess) a gazillion registers related to its deep-core SoC stuff should be handled by things like drivers/mfd/syscon.c, which means it is dead simple for some other driver using just this one register in that range to get a handle at it and poke it using syscon_node_to_regmap() (just derference an ampersand ref) syscon_regmap_lookup_by_compatible() (use a compatible string) all returning a regmap * that you can use to poke these registers. The register handling is fine. But how do we deal with resource handling? e.g. the block that has the deep-core registers might need to be clocked or powered before the registers can be accessed. 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] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Hi Tomi, On Fri, Oct 11, 2013 at 10:17 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote: I am not sure if there is a SPI driver for a McBSP port [1]? And to make that work (reliably) and tested it might need a lot of work for us. At least I think such a change (e.g. setting up clock polarity etc.) is not done in some minutes. And the only feedback we have from the panel is does not work/works. I.e. if we are not lucky that it works immediately we have no real means to debug. IMHO it also gives more flexibility to board designers to choose GPIOs instead of enforcing some SPI interface by the driver (and encapsulate this arguable protocol in the driver). Maybe some board has 3 spare GPIOs but neither McBSPs nor McSPIs available. This has been an interesting thread, I've learnt a lot =). I still think the panel driver should not handle this, but there should be a separate spi bitbang driver for it. I understand you're not enthusiastic going that way, as the current version works for you. However, when using DT, we need to think how to represent the hardware in the device tree data, and it has to be right from the beginning. That's why I won't allow representing this panel as having 4 gpios in the DT data, because that is not correct. The panel has 3 pins. But then, the panel does allow reading, which could be implemented using 4 gpios as you have done. This data should be in the spi-bitbang data, and the panel should just use the standard SPI framework. I disagree. There are different drivers which pass in platform data gpios (encoder-tfp410.c or encoder-tpd12s015.c) and those must be covered by DT then. I cannot see problem why to have for td028 panel 3 or 4 gpios defined in DT. Using SPI framework does not mean you should use McBSP or McSPI. It's up to you how the 3-wire SPI is implemented on the SoC side, the panel would just work in all the cases. Tomi BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.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] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
On 10/11/2013 10:59 AM, Belisko Marek wrote: Hi Tomi, On Fri, Oct 11, 2013 at 10:17 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote: I am not sure if there is a SPI driver for a McBSP port [1]? And to make that work (reliably) and tested it might need a lot of work for us. At least I think such a change (e.g. setting up clock polarity etc.) is not done in some minutes. And the only feedback we have from the panel is does not work/works. I.e. if we are not lucky that it works immediately we have no real means to debug. IMHO it also gives more flexibility to board designers to choose GPIOs instead of enforcing some SPI interface by the driver (and encapsulate this arguable protocol in the driver). Maybe some board has 3 spare GPIOs but neither McBSPs nor McSPIs available. This has been an interesting thread, I've learnt a lot =). I still think the panel driver should not handle this, but there should be a separate spi bitbang driver for it. I understand you're not enthusiastic going that way, as the current version works for you. However, when using DT, we need to think how to represent the hardware in the device tree data, and it has to be right from the beginning. That's why I won't allow representing this panel as having 4 gpios in the DT data, because that is not correct. The panel has 3 pins. But then, the panel does allow reading, which could be implemented using 4 gpios as you have done. This data should be in the spi-bitbang data, and the panel should just use the standard SPI framework. I disagree. There are different drivers which pass in platform data gpios (encoder-tfp410.c or encoder-tpd12s015.c) and those must be covered by DT then. I cannot see problem why to have for td028 panel 3 or 4 gpios defined in DT. The problem is not representing it in the devicetree, but representing it correctly. This is a SPI slave device, hence it should be presented in the devicetree as a SPI slave device and not as a platform device with 4 GPIOs. - Lars -- 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] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
On 11/10/13 11:59, Belisko Marek wrote: That's why I won't allow representing this panel as having 4 gpios in the DT data, because that is not correct. The panel has 3 pins. But then, the panel does allow reading, which could be implemented using 4 gpios as you have done. This data should be in the spi-bitbang data, and the panel should just use the standard SPI framework. I disagree. There are different drivers which pass in platform data gpios (encoder-tfp410.c or encoder-tpd12s015.c) and those must be covered by DT then. I cannot see problem why to have for td028 panel 3 or 4 gpios defined in DT. Yes, they are plain GPIOs, and defined in the spec for the respective chip. There's no alternative to how they could be represented. Here, with the td028, the spec speaks of 3 pins for the serial bus. Not 4. So there cannot be 4 gpios defined in the panel's data, that just doesn't make sense. Additionally, what we have here are not normal gpios, but pins for a serial bus, 3-wire SPI. If the panel data specifies the gpios, then it's not possible to use real SPI hardware with the panel. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Hi all, Am 11.10.2013 um 11:06 schrieb Lars-Peter Clausen: On 10/11/2013 10:59 AM, Belisko Marek wrote: Hi Tomi, On Fri, Oct 11, 2013 at 10:17 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 11/10/13 10:42, Dr. H. Nikolaus Schaller wrote: I am not sure if there is a SPI driver for a McBSP port [1]? And to make that work (reliably) and tested it might need a lot of work for us. At least I think such a change (e.g. setting up clock polarity etc.) is not done in some minutes. And the only feedback we have from the panel is does not work/works. I.e. if we are not lucky that it works immediately we have no real means to debug. IMHO it also gives more flexibility to board designers to choose GPIOs instead of enforcing some SPI interface by the driver (and encapsulate this arguable protocol in the driver). Maybe some board has 3 spare GPIOs but neither McBSPs nor McSPIs available. This has been an interesting thread, I've learnt a lot =). I still think the panel driver should not handle this, but there should be a separate spi bitbang driver for it. I understand you're not enthusiastic going that way, as the current version works for you. However, when using DT, we need to think how to represent the hardware in the device tree data, and it has to be right from the beginning. That's why I won't allow representing this panel as having 4 gpios in the DT data, because that is not correct. The panel has 3 pins. But then, the panel does allow reading, which could be implemented using 4 gpios as you have done. This data should be in the spi-bitbang data, and the panel should just use the standard SPI framework. I disagree. There are different drivers which pass in platform data gpios (encoder-tfp410.c or encoder-tpd12s015.c) and those must be covered by DT then. I cannot see problem why to have for td028 panel 3 or 4 gpios defined in DT. The problem is not representing it in the devicetree, but representing it correctly. This is a SPI slave device, hence it should be presented in the devicetree as a SPI slave device and not as a platform device with 4 GPIOs. Hm. Is this a SPI or does it just look like one? Or is it some - otherwise unknown - 3 wire serial interface. Or is it a 3(+1) GPIO slave device? I am still not sure about this. If we really want to do it correctly, we may have to write a driver for that special serial protocol as well. If it turns out that we can't mis-use and tweak it into a standard SPI driver with bit-bang backend. I simply fear that we get dependencies with the SPI subsystem and have to test, debug and maintain it. Maintaining the GPIO thing we currently have is easy. What would be against taking the GPIO approach first and then upgrade as soon as someone raises his/her finger that he/she wants to really interface this display differently and is not happy with the 3/4 GPIOs? Either they come up with a patch or contact the driver author (=me). BR, Nikolaus -- 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] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
On 11/10/13 12:50, Dr. H. Nikolaus Schaller wrote: Hm. Is this a SPI or does it just look like one? Or is it some - otherwise unknown - 3 wire serial interface. Or is it a 3(+1) GPIO slave device? I am still not sure about this. Lars-Peter said Back in the OpenMoko days we used the panel in normal 4-wire SPI mode with the GPIO bitbang SPI master. I don't know much about SPI, so I can't answer to that. If the serial bus is indeed not any kind of more or less standard SPI version, but really a custom bus for this controller, then the case is a bit unclear. If we really want to do it correctly, we may have to write a driver for that special serial protocol as well. If it turns out that we can't mis-use and tweak it into a standard SPI driver with bit-bang backend. I simply fear that we get dependencies with the SPI subsystem and have to test, debug and maintain it. Maintaining the GPIO thing we currently have is easy. What would be against taking the GPIO approach first and then upgrade as soon as someone raises his/her finger that he/she wants to really interface this display differently and is not happy with the 3/4 GPIOs? Either they come up with a patch or contact the driver author (=me). I don't have anything against that as long as we use only platform data. But DT data is not an in-kernel API, it's an external API. Once we define that the DT data for this panel is something, that's it, we should stick to it. Of course, we can build compatibility layers for old DT data, but I would avoid that if at all possible. If we now create the DT data with gpios, and the panel as platform device, it'd be rather nasty change to make it a child of an spi bus. (I presume, I have never made such a change). And, as the gpios and platform device approach is clearly wrong way to describe the hardware, I'm quite against using that description in the DT data. That said, one option is to describe the hardware correctly in the DT data, but have a platform device for the panel, with panel driver doing the bitbanging. In that case it is possible to update the system to use SPI framework if needed, without changing the DT data. However, I'm not sure how easy that would be. Tomi signature.asc Description: OpenPGP digital signature
RE: [PATCH v7 1/6] mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes
Dear MTD Maintainers,
If I have my NAND formatted with one of the existing ECC schemes (e.g.
OMAP_ECC_HAMMING_CODE_DEFAULT) will it work with the new
OMAP_ECC_HAM1_CODE_HW scheme?
Are they all compatible?
Yes, they all are 1-bit hamming code, the only difference between
xx_Default and xx_HW was who was doing the ECC calculation.
For xx_DEFAULT: ECC calculation was done on CPU via s/w library
For xx_HW: ECC calculation was done by in-build h/w engine.
So, all HAMMING_xx can be replaced by HAM1_HW.
[snip]
@@ -1342,9 +1342,7 @@ static void __maybe_unused
gpmc_read_timings_dt(struct device_node *np,
#ifdef CONFIG_MTD_NAND
static const char * const nand_ecc_opts[] = {
- [OMAP_ECC_HAMMING_CODE_DEFAULT] = sw,
- [OMAP_ECC_HAMMING_CODE_HW] = hw,
- [OMAP_ECC_HAMMING_CODE_HW_ROMCODE] = hw-
romcode,
+ [OMAP_ECC_HAM1_CODE_HW] = ham1,
[OMAP_ECC_BCH4_CODE_HW] = bch4,
[OMAP_ECC_BCH8_CODE_HW] = bch8,
Won't this break existing dts which have sw, hw, or hw-romcode?
Someone may try to use a new kernel with an old dt, and we marked them
as deprecated, not removed.
HAMMING_xx ECC scheme was used only on legacy platforms, when
BCH8 was not available, I have not seen anyone using this scheme
*from mainline kernel* from quite a long time. So, it's safe to remove them.
This is what was concluded as per below email.
http://lists.infradead.org/pipermail/linux-mtd/2013-September/048876.html
This patch-series and its follow-on series has already missed many merge
windows, And the above discussion has reached a stalled state (infinite loop)
where, I cannot revert some DT binding updates to and fro to keep all legacy
DT bindings backward compatible forever.
However, I can assure that these DT updates make binding stable for long-term.
So now it's your discretion to whether to accept or leave following 2 series:
http://lists.infradead.org/pipermail/linux-mtd/2013-October/048983.html
http://lists.infradead.org/pipermail/linux-mtd/2013-October/049008.html
AFAIK no-one is using Hamming based ecc-scheme on OMAP platforms
*from mainline kernel*. So this DT update actually does not affect users
I know of. Rather these patch series was intended for long term scalability
and clean-up so that more OMAP users migrate to mainline kernel easily.
with regards, pekon
--
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/6] pinctrl: single: Add support for wake-up interrupts
On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros rog...@ti.com wrote: The register handling is fine. But how do we deal with resource handling? e.g. the block that has the deep-core registers might need to be clocked or powered before the registers can be accessed. Yeah I saw this in the code there. In this case it seems syscon-type regmap access can be used to read/write the registers, so maybe the pin controller also need to get a handle on some clock etc? The general idea is however that large monolitic drivers for a certain IO-range such as arch/arm/mach-omap2/prm3xxx.c doesn't scale - we saw this with the Ux500 PRCMU driver in mfd/* to the point that our patches to extend it were NACK:ed until we refactor it. This stuff in mach-omap2 is in the same bad design pattern, and need to get out of it. The approach chosen for the Ux500 PRCMU was to distribute out the driver into the places where it's actually used, like the clock driver etc. The accessor functions to do some stuff over in the PRCMU was just adding a layer of cruft. Yours, Linus Walleij -- 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] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Hi Tomi, Am 11.10.2013 um 12:09 schrieb Tomi Valkeinen: On 11/10/13 12:50, Dr. H. Nikolaus Schaller wrote: Hm. Is this a SPI or does it just look like one? Or is it some - otherwise unknown - 3 wire serial interface. Or is it a 3(+1) GPIO slave device? I am still not sure about this. Lars-Peter said Back in the OpenMoko days we used the panel in normal 4-wire SPI mode with the GPIO bitbang SPI master. I don't know much about SPI, so I can't answer to that. If the serial bus is indeed not any kind of more or less standard SPI version, but really a custom bus for this controller, then the case is a bit unclear. I have thought over lunch time that it is worth to look into how the Openmoko did physically hook up the display and if parts of that code (it was for 2.6.26 or so and for a Samsung SoC) is understandable and reusable (e.g. hints how to set up the board file for a bitbang SPI on OMAP3 - we have never done this before). If we really want to do it correctly, we may have to write a driver for that special serial protocol as well. If it turns out that we can't mis-use and tweak it into a standard SPI driver with bit-bang backend. I simply fear that we get dependencies with the SPI subsystem and have to test, debug and maintain it. Maintaining the GPIO thing we currently have is easy. What would be against taking the GPIO approach first and then upgrade as soon as someone raises his/her finger that he/she wants to really interface this display differently and is not happy with the 3/4 GPIOs? Either they come up with a patch or contact the driver author (=me). I don't have anything against that as long as we use only platform data. But DT data is not an in-kernel API, it's an external API. Once we define that the DT data for this panel is something, that's it, we should stick to it. Of course, we can build compatibility layers for old DT data, but I would avoid that if at all possible. Ah, I see. I already think that using the DT makes such things not easier but more difficult - but I am not at all familiar with it. If we now create the DT data with gpios, and the panel as platform device, it'd be rather nasty change to make it a child of an spi bus. (I presume, I have never made such a change). And, as the gpios and platform device approach is clearly wrong way to describe the hardware, I'm quite against using that description in the DT data. Since we are not familiar with DT yet, it is difficult to see the consequences of such a step. That said, one option is to describe the hardware correctly in the DT data, but have a platform device for the panel, with panel driver doing the bitbanging. In that case it is possible to update the system to use SPI framework if needed, without changing the DT data. However, I'm not sure how easy that would be. Sounds quite complex, indeed. So our next step will be to look into the GTA02 SPI thing to get more knowlegde about thier solution. BR, Nikolaus -- 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 v7 1/6] mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes
Hi Pekon,
On Fri, Oct 11, 2013 at 05:17:48AM -0500, Gupta, Pekon wrote:
If I have my NAND formatted with one of the existing ECC schemes (e.g.
OMAP_ECC_HAMMING_CODE_DEFAULT) will it work with the new
OMAP_ECC_HAM1_CODE_HW scheme?
Are they all compatible?
Yes, they all are 1-bit hamming code, the only difference between
xx_Default and xx_HW was who was doing the ECC calculation.
For xx_DEFAULT: ECC calculation was done on CPU via s/w library
For xx_HW: ECC calculation was done by in-build h/w engine.
So, all HAMMING_xx can be replaced by HAM1_HW.
[snip]
@@ -1342,9 +1342,7 @@ static void __maybe_unused
gpmc_read_timings_dt(struct device_node *np,
#ifdef CONFIG_MTD_NAND
static const char * const nand_ecc_opts[] = {
- [OMAP_ECC_HAMMING_CODE_DEFAULT] = sw,
- [OMAP_ECC_HAMMING_CODE_HW] = hw,
- [OMAP_ECC_HAMMING_CODE_HW_ROMCODE] = hw-
romcode,
+ [OMAP_ECC_HAM1_CODE_HW] = ham1,
[OMAP_ECC_BCH4_CODE_HW] = bch4,
[OMAP_ECC_BCH8_CODE_HW] = bch8,
Won't this break existing dts which have sw, hw, or hw-romcode?
Someone may try to use a new kernel with an old dt, and we marked them
as deprecated, not removed.
HAMMING_xx ECC scheme was used only on legacy platforms, when
BCH8 was not available, I have not seen anyone using this scheme
*from mainline kernel* from quite a long time. So, it's safe to remove them.
This is what was concluded as per below email.
http://lists.infradead.org/pipermail/linux-mtd/2013-September/048876.html
This patch-series and its follow-on series has already missed many merge
windows, And the above discussion has reached a stalled state (infinite loop)
where, I cannot revert some DT binding updates to and fro to keep all legacy
DT bindings backward compatible forever.
However, I can assure that these DT updates make binding stable for long-term.
So now it's your discretion to whether to accept or leave following 2 series:
http://lists.infradead.org/pipermail/linux-mtd/2013-October/048983.html
http://lists.infradead.org/pipermail/linux-mtd/2013-October/049008.html
AFAIK no-one is using Hamming based ecc-scheme on OMAP platforms
*from mainline kernel*. So this DT update actually does not affect users
I know of. Rather these patch series was intended for long term scalability
and clean-up so that more OMAP users migrate to mainline kernel easily.
wouldn't something like below maintain backwards compatibility ?
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 579697a..f33ffe0 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1383,6 +1383,10 @@ static int gpmc_probe_nand_child(struct platform_device
*pdev,
if (!strcasecmp(s, nand_ecc_opts[val])) {
gpmc_nand_data-ecc_opt = val;
break;
+ } else if (!strcasecmp(s, sw) ||
+ !strcasecmp(s, hw) ||
+ !strcasecmp(s, hw-romcode)) {
+ gpmc_nand_data-ecc_opt = OMAP_ECC_HAM1_CODE_HW;
}
if (!of_property_read_string(child, ti,nand-xfer-type, s))
--
balbi
signature.asc
Description: Digital signature
[PATCH v8 0/6] mtd:nand:omap2: clean-up of supported ECC schemes
*Changes v7 - v8* [PATCH 1/6] no updates [PATCH 2/6] - updated DT parsing of ti,nand-ecc-opts so that its ham1 remains compatible to sw,hw,hw-romcode - updated DT parsing of ti,elm-id to retain compatibility to elm_id - using of_parse_phandle() to get ELM device pointer from DT [PATCH 3..6/6] commit log updates *Changes v6 - v7* [PATCH 1/6] NEW split from [PATCH v6 2/4] as per feedbacks of Brain Norris [PATCH 2/6] incorporated feedbacks from DT maintainers [PATCH 3/6] patch cleaning and incorporated feedbacks from Brain Norris [PATCH 4/6] rebasing changes and cleanup [PATCH 5/6] updated omap3430-sdp.dts [PATCH 6/6] NEW updated for devm_xx *Changes v5 - v6* [PATCH 1/4]: - updated DT binding for gpmc-nand based on 'Olof Johansson's feedbacks http://lists.infradead.org/pipermail/linux-mtd/2013-August/048394.html - detection of ELM device via ti,elm-id DT node, moved to gpmc.c driver [PATCH 2/4] - removed: support for following obselete ECC schemes OMAP_ECC_HAMMING_CODE_DEFAULT (S/W based 1-bit Hamming ECC) OMAP_ECC_HAMMING_CODE_HW_ROMCODE (H/W based 1-bit Hamming ECC scheme) - updated: using omap_oobinfo as chip-ecc.layout for all ecc-schemes - clean: error messages [PATCH 3/4] cleaned to include changes for OMAP_ECC_BCH8_CODE_HW only [PATCH 4/4] updated to include DT property changes *Changes v4 - v5* - Rebased to linux-next IMPORTANT: Need to revert commit fb1585b, [PATCH 2/4] part of previous version http://lists.infradead.org/pipermail/linux-mtd/2013-July/047441.html - Swapped PATCH-1 PATCH-2 to maintain bisectibility compilation dependency http://lists.infradead.org/pipermail/linux-mtd/2013-July/047461.html - PATCH-2: re-ordered call to is_elm_present() for later updates ELM driver - dropped changes in include/linux/platform_data/elm.h (not needed) - PATCH-3: re-ordered call to is_elm_present() for later updates ELM driver - Re-formated patch description (replaced tabs with white-spaces) *Changes v3 - v4* (Resent with CC: devicetree-disc...@lists.ozlabs.org) - [Patch 1/3] removed MTD_NAND_OMAP_BCH8 MTD_NAND_OMAP_BCH4 from nand/Kconfig ECC scheme selectable via nand DT (nand-ecc-opt). - [*] rebased for l2-mtd.git *Changes v2 - v3* (Resent with Author Name fixed) - PATCH-1: re-arranged code to remove redundancy, added NAND_BUSWIDTH_AUTO - PATCH-2: updated nand-ecc-opt DT mapping and Documentation - PATCH-3: code-cleaning + changes to match PATCH-1 - PATCH-4 DROPPED update DT attribute for ti,nand-ecc-opt - received feedback to keep DT mapping independent of linuxism - PATCH-4:NEW : ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt - independent patch for AM335x-evm.dts update based on PATCH-2 *Changes v1 - v2* added [PATCH 3/4] and [PATCH 4/4] After this patch series, omap2-nand driver will supports following ECC schemes: +---+---+---+ | ECC scheme|ECC calculation|Error detection| +---+---+---+ |OMAP_ECC_HAM1_CODE_HW |H/W (GPMC) |S/W| +---+---+---+ |OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH4_CODE_HW |H/W (GPMC) |H/W (ELM) | +---+---+---+ |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)| |OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) | +---+---+---+ To optimize footprint of omap2-nand driver, selection of some ECC schemes also require enabling following Kconfigs, in addition to setting appropriate DT bindings - Kconfig:CONFIG_MTD_NAND_ECC_BCHerror detection done in software - Kconfig:CONFIG_MTD_NAND_OMAP_BCH error detection done by h/w engine Pekon Gupta (6): mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes ARM: OMAP2+: cleaned-up DT support of various ECC schemes mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe mtd:nand:omap2: updated support for BCH4 ECC scheme ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt mtd: nand: omap: updated devm_xx for all resource allocation and free calls .../devicetree/bindings/mtd/gpmc-nand.txt | 16 +- arch/arm/boot/dts/am335x-evm.dts | 3 +- arch/arm/boot/dts/omap3430-sdp.dts | 2 +- arch/arm/mach-omap2/board-flash.c | 2 +- arch/arm/mach-omap2/gpmc.c | 47 +- drivers/mtd/nand/Kconfig | 30 +- drivers/mtd/nand/omap2.c | 569 ++---
[PATCH v8 1/6] mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes
OMAP NAND driver currently supports multiple flavours of 1-bit Hamming
ecc-scheme, like:
- OMAP_ECC_HAMMING_CODE_DEFAULT
1-bit hamming ecc code using software library
- OMAP_ECC_HAMMING_CODE_HW
1-bit hamming ecc-code using GPMC h/w engine
- OMAP_ECC_HAMMING_CODE_HW_ROMCODE
1-bit hamming ecc-code using GPMC h/w engin with ecc-layout compatible
to ROM code.
This patch combines above multiple ecc-schemes into single implementation:
- OMAP_ECC_HAM1_CODE_HW
1-bit hamming ecc-code using GPMC h/w engine with ROM-code compatible
ecc-layout.
Signed-off-by: Pekon Gupta pe...@ti.com
---
Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 8
arch/arm/mach-omap2/board-flash.c | 2 +-
arch/arm/mach-omap2/gpmc.c | 4 +---
drivers/mtd/nand/omap2.c| 9 +++--
include/linux/platform_data/mtd-nand-omap2.h| 6 +-
5 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index df338cb..25ee232 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -22,10 +22,10 @@ Optional properties:
width of 8 is assumed.
- ti,nand-ecc-opt:A string setting the ECC layout to use. One of:
-
- swSoftware method (default)
- hwHardware method
- hw-romcodegpmc hamming mode method romcode layout
+ swdeprecated use ham1 instead
+ hwdeprecated use ham1 instead
+ hw-romcodedeprecated use ham1 instead
+ ham1 1-bit Hamming ecc code
bch4 4-bit BCH ecc code
bch8 8-bit BCH ecc code
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index fc20a61..ac82512 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -142,7 +142,7 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8
nr_parts, u8 cs,
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
- board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
+ board_nand_data.ecc_opt = OMAP_ECC_BCH8_CODE_HW;
gpmc_nand_init(board_nand_data, gpmc_t);
}
#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 579697a..c9fb353 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1342,9 +1342,7 @@ static void __maybe_unused gpmc_read_timings_dt(struct
device_node *np,
#ifdef CONFIG_MTD_NAND
static const char * const nand_ecc_opts[] = {
- [OMAP_ECC_HAMMING_CODE_DEFAULT] = sw,
- [OMAP_ECC_HAMMING_CODE_HW] = hw,
- [OMAP_ECC_HAMMING_CODE_HW_ROMCODE] = hw-romcode,
+ [OMAP_ECC_HAM1_CODE_HW] = ham1,
[OMAP_ECC_BCH4_CODE_HW] = bch4,
[OMAP_ECC_BCH8_CODE_HW] = bch8,
};
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 4ecf0e5..8d521aa 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1993,10 +1993,7 @@ static int omap_nand_probe(struct platform_device *pdev)
}
/* select the ecc type */
- if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_DEFAULT)
- info-nand.ecc.mode = NAND_ECC_SOFT;
- else if ((pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW) ||
- (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE)) {
+ if (pdata-ecc_opt == OMAP_ECC_HAM1_CODE_HW) {
info-nand.ecc.bytes= 3;
info-nand.ecc.size = 512;
info-nand.ecc.strength = 1;
@@ -2025,7 +2022,7 @@ static int omap_nand_probe(struct platform_device *pdev)
}
/* rom code layout */
- if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE) {
+ if (pdata-ecc_opt == OMAP_ECC_HAM1_CODE_HW) {
if (info-nand.options NAND_BUSWIDTH_16)
offset = 2;
@@ -2033,7 +2030,7 @@ static int omap_nand_probe(struct platform_device *pdev)
offset = 1;
info-nand.badblock_pattern = bb_descrip_flashbased;
}
- omap_oobinfo.eccbytes = 3 * (info-mtd.oobsize/16);
+ omap_oobinfo.eccbytes = 3 * (info-mtd.writesize / 512);
for (i = 0; i omap_oobinfo.eccbytes; i++)
omap_oobinfo.eccpos[i] = i+offset;
diff --git a/include/linux/platform_data/mtd-nand-omap2.h
b/include/linux/platform_data/mtd-nand-omap2.h
index 6bf9ef4..cb5a54a 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
[PATCH v8 2/6] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
OMAP NAND driver support multiple ECC scheme, which can used in following
different flavours, depending on in-build Hardware engines supported by SoC.
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAM1_CODE_HW |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
|(requires CONFIG_MTD_NAND_ECC_BCH) | | |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
|(requires CONFIG_MTD_NAND_OMAP_BCH | | |
| ti,elm-id in DT) | | |
+---+---+---+
To optimize footprint of omap2-nand driver, selection of some ECC schemes
also require enabling following Kconfigs, in addition to setting appropriate
DT bindings
- Kconfig:CONFIG_MTD_NAND_ECC_BCHerror detection done in software
- Kconfig:CONFIG_MTD_NAND_OMAP_BCH error detection done by h/w engine
DT binding updates in this patch are:
- ti,elm-id: replaces elm_id
- ti,nand-ecc-opts: supported values ham1, bch4, and bch8
selection of h/w or s/w implementation depends on ti,elm-id
Signed-off-by: Pekon Gupta pe...@ti.com
---
.../devicetree/bindings/mtd/gpmc-nand.txt | 8 +++-
arch/arm/mach-omap2/gpmc.c | 45 --
include/linux/platform_data/mtd-nand-omap2.h | 14 +--
3 files changed, 50 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index 25ee232..5e1f31b 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -36,8 +36,12 @@ Optional properties:
prefetch-dma Prefetch enabled sDMA mode
prefetch-irq Prefetch enabled irq mode
- - elm_id: Specifies elm device node. This is required to support BCH
- error correction using ELM module.
+ - elm_id: deprecated use ti,elm-id instead
+ - ti,elm-id: Specifies phandle of the ELM devicetree node.
+ ELM is an on-chip hardware engine on TI SoC which is used for
+ locating ECC errors for BCHx algorithms. SoC devices which have
+ ELM hardware engines should specify this device node in .dtsi
+ Using ELM for ECC error correction frees some CPU cycles.
For inline partiton table parsing (optional):
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index c9fb353..9473c9f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1341,12 +1341,6 @@ static void __maybe_unused gpmc_read_timings_dt(struct
device_node *np,
#ifdef CONFIG_MTD_NAND
-static const char * const nand_ecc_opts[] = {
- [OMAP_ECC_HAM1_CODE_HW] = ham1,
- [OMAP_ECC_BCH4_CODE_HW] = bch4,
- [OMAP_ECC_BCH8_CODE_HW] = bch8,
-};
-
static const char * const nand_xfer_types[] = {
[NAND_OMAP_PREFETCH_POLLED] = prefetch-polled,
[NAND_OMAP_POLLED] = polled,
@@ -1376,12 +1370,39 @@ static int gpmc_probe_nand_child(struct platform_device
*pdev,
gpmc_nand_data-cs = val;
gpmc_nand_data-of_node = child;
- if (!of_property_read_string(child, ti,nand-ecc-opt, s))
- for (val = 0; val ARRAY_SIZE(nand_ecc_opts); val++)
- if (!strcasecmp(s, nand_ecc_opts[val])) {
- gpmc_nand_data-ecc_opt = val;
- break;
- }
+ /* Detect availability of ELM module */
+ gpmc_nand_data-elm_of_node = of_parse_phandle(child, ti,elm-id, 0);
+ if (gpmc_nand_data-elm_of_node == NULL)
+ gpmc_nand_data-elm_of_node =
+ of_parse_phandle(child, elm_id, 0);
+ if (gpmc_nand_data-elm_of_node == NULL)
+ pr_warn(%s: ti,elm-id property not found\n, __func__);
+
+ /* select NAND ecc-opt */
+ if (of_property_read_string(child, ti,nand-ecc-opt, s)) {
+ pr_err(%s: ti,nand-ecc-opt not found\n, __func__);
+ return -ENODEV;
+ }
+ if (!strcmp(s, ham1) || !strcmp(s, sw) ||
+ !strcmp(s, hw) || !strcmp(s, hw-romcode))
+ gpmc_nand_data-ecc_opt =
+ OMAP_ECC_HAM1_CODE_HW;
+ else if (!strcmp(s, bch4))
+ if (gpmc_nand_data-elm_of_node)
+
[PATCH v8 3/6] mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe
OMAP NAND driver support multiple ECC scheme, which can used in following
different flavours, depending on in-build Hardware engines supported by SoC.
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAM1_CODE_HW |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
|(requires CONFIG_MTD_NAND_ECC_BCH) | | |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
|(requires CONFIG_MTD_NAND_OMAP_BCH | | |
| ti,elm-id in DT) | | |
+---+---+---+
To optimize footprint of omap2-nand driver, selection of some ECC schemes
also require enabling following Kconfigs, in addition to setting appropriate
DT bindings
- Kconfig:CONFIG_MTD_NAND_ECC_BCHenables S/W based BCH ECC algorithm
- Kconfig:CONFIG_MTD_NAND_OMAP_BCH enables H/W based BCH ECC algorithm
This patch
- separates the configurations code for each ECC schemes
- fixes dependency issues based on Kconfig options
- updates ELM device detection in is_elm_present()
- cleans redundant code
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/omap2.c | 450 +++
1 file changed, 220 insertions(+), 230 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 8d521aa..fb96251 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -25,8 +25,10 @@
#include linux/of.h
#include linux/of_device.h
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
+#ifdef CONFIG_MTD_NAND_ECC_BCH
#include linux/bch.h
+#endif
+#ifdef CONFIG_MTD_NAND_OMAP_BCH
#include linux/platform_data/elm.h
#endif
@@ -141,6 +143,9 @@
#define BCH_ECC_SIZE0 0x0 /* ecc_size0 = 0, no oob protection */
#define BCH_ECC_SIZE1 0x20/* ecc_size1 = 32 */
+#define BADBLOCK_MARKER_LENGTH 2
+#define OMAP_ECC_BCH8_POLYNOMIAL 0x201b
+
#ifdef CONFIG_MTD_NAND_OMAP_BCH
static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
0xac, 0x6b, 0xff, 0x99, 0x7b};
@@ -182,14 +187,11 @@ struct omap_nand_info {
u_char *buf;
int buf_len;
struct gpmc_nand_regs reg;
-
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
- struct bch_control *bch;
- struct nand_ecclayout ecclayout;
+ /* fields specific for BCHx_HW ECC scheme */
+ struct bch_control *bch;
boolis_elm_used;
struct device *elm_dev;
struct device_node *of_node;
-#endif
};
/**
@@ -1058,8 +1060,7 @@ static int omap_dev_ready(struct mtd_info *mtd)
}
}
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
-
+#if defined(CONFIG_MTD_NAND_ECC_BCH) || defined(CONFIG_MTD_NAND_OMAP_BCH)
/**
* omap3_enable_hwecc_bch - Program OMAP3 GPMC to perform BCH ECC correction
* @mtd: MTD device structure
@@ -1140,7 +1141,9 @@ static void omap3_enable_hwecc_bch(struct mtd_info *mtd,
int mode)
/* Clear ecc and enable bits */
writel(ECCCLEAR | ECC1, info-reg.gpmc_ecc_control);
}
+#endif
+#ifdef CONFIG_MTD_NAND_ECC_BCH
/**
* omap3_calculate_ecc_bch4 - Generate 7 bytes of ECC bytes
* @mtd: MTD device structure
@@ -1225,7 +1228,9 @@ static int omap3_calculate_ecc_bch8(struct mtd_info *mtd,
const u_char *dat,
return 0;
}
+#endif /* CONFIG_MTD_NAND_ECC_BCH */
+#ifdef CONFIG_MTD_NAND_OMAP_BCH
/**
* omap3_calculate_ecc_bch - Generate bytes of ECC bytes
* @mtd: MTD device structure
@@ -1517,7 +1522,9 @@ static int omap_elm_correct_data(struct mtd_info *mtd,
u_char *data,
return stat;
}
+#endif /* CONFIG_MTD_NAND_OMAP_BCH */
+#ifdef CONFIG_MTD_NAND_ECC_BCH
/**
* omap3_correct_data_bch - Decode received data and correct errors
* @mtd: MTD device structure
@@ -1549,7 +1556,9 @@ static int omap3_correct_data_bch(struct mtd_info *mtd,
u_char *data,
}
return count;
}
+#endif /* CONFIG_MTD_NAND_ECC_BCH */
+#ifdef CONFIG_MTD_NAND_OMAP_BCH
/**
* omap_write_page_bch - BCH ecc based write page function for entire page
* @mtd: mtd info structure
@@ -1637,197 +1646,68 @@ static int omap_read_page_bch(struct mtd_info *mtd,
struct nand_chip *chip,
}
/**
- * omap3_free_bch - Release BCH ecc resources
- * @mtd: MTD device structure
+ * is_elm_present - checks for presence of ELM module by scanning DT nodes
+ * @omap_nand_info: NAND device structure
[PATCH v8 4/6] mtd:nand:omap2: updated support for BCH4 ECC scheme
This patch adds following two flavours of BCH4 ECC scheme in omap2-nand driver
- OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
- uses GPMC H/W engine for calculating ECC.
- uses software library (lib/bch.h nand_bch.h) for error correction.
- OMAP_ECC_BCH4_CODE_HW
- uses GPMC H/W engine for calculating ECC.
- uses ELM H/W engine for error correction.
With this patch omap2-nand driver supports following ECC schemes:
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAM1_CODE_HW |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)|
|OMAP_ECC_BCH4_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)|
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
Important:
- Selection of OMAP_ECC_BCHx_CODE_HW_DETECTION_SW requires,
Kconfig: CONFIG_MTD_NAND_ECC_BCH: enables S/W based BCH ECC algorithm.
- Selection of OMAP_ECC_BCHx_CODE_HW requires,
Kconfig: CONFIG_MTD_NAND_OMAP_BCH: enables ELM H/W module.
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/Kconfig | 30 ++-
drivers/mtd/nand/omap2.c | 134 +--
2 files changed, 63 insertions(+), 101 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index d885298..5836039 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -96,35 +96,13 @@ config MTD_NAND_OMAP2
config MTD_NAND_OMAP_BCH
depends on MTD_NAND MTD_NAND_OMAP2 ARCH_OMAP3
- tristate Enable support for hardware BCH error correction
+ tristate Support hardware based BCH error correction
default n
select BCH
- select BCH_CONST_PARAMS
help
-Support for hardware BCH error correction.
-
-choice
- prompt BCH error correction capability
- depends on MTD_NAND_OMAP_BCH
-
-config MTD_NAND_OMAP_BCH8
- bool 8 bits / 512 bytes (recommended)
- help
-Support correcting up to 8 bitflips per 512-byte block.
-This will use 13 bytes of spare area per 512 bytes of page data.
-This is the recommended mode, as 4-bit mode does not work
-on some OMAP3 revisions, due to a hardware bug.
-
-config MTD_NAND_OMAP_BCH4
- bool 4 bits / 512 bytes
- help
-Support correcting up to 4 bitflips per 512-byte block.
-This will use 7 bytes of spare area per 512 bytes of page data.
-Note that this mode does not work on some OMAP3 revisions, due to a
-hardware bug. Please check your OMAP datasheet before selecting this
-mode.
-
-endchoice
+ Some devices have built-in ELM hardware engine, which can be used to
+ locate and correct errors when using BCH ECC scheme. This enables the
+ driver support for same.
if MTD_NAND_OMAP_BCH
config BCH_CONST_M
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index fb96251..a783dae 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -27,6 +27,7 @@
#ifdef CONFIG_MTD_NAND_ECC_BCH
#include linux/bch.h
+#include linux/mtd/nand_bch.h
#endif
#ifdef CONFIG_MTD_NAND_OMAP_BCH
#include linux/platform_data/elm.h
@@ -144,7 +145,6 @@
#define BCH_ECC_SIZE1 0x20/* ecc_size1 = 32 */
#define BADBLOCK_MARKER_LENGTH 2
-#define OMAP_ECC_BCH8_POLYNOMIAL 0x201b
#ifdef CONFIG_MTD_NAND_OMAP_BCH
static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
@@ -188,7 +188,6 @@ struct omap_nand_info {
int buf_len;
struct gpmc_nand_regs reg;
/* fields specific for BCHx_HW ECC scheme */
- struct bch_control *bch;
boolis_elm_used;
struct device *elm_dev;
struct device_node *of_node;
@@ -1522,43 +1521,7 @@ static int omap_elm_correct_data(struct mtd_info *mtd,
u_char *data,
return stat;
}
-#endif /* CONFIG_MTD_NAND_OMAP_BCH */
-#ifdef CONFIG_MTD_NAND_ECC_BCH
-/**
- * omap3_correct_data_bch - Decode received data and correct errors
- * @mtd: MTD device structure
- * @data: page data
- * @read_ecc: ecc read from nand flash
- * @calc_ecc: ecc read from HW ECC registers
- */
-static int omap3_correct_data_bch(struct mtd_info *mtd, u_char *data,
- u_char *read_ecc, u_char *calc_ecc)
-{
- int i, count;
- /* cannot correct more
[PATCH v8 5/6] ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt
Updated DTS to replace deprecated binding with newer values
Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 3 +--
arch/arm/boot/dts/omap3430-sdp.dts | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e8ec875..1aee6ac 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -269,7 +269,6 @@
reg = 0 0 0; /* CS0, offset 0 */
nand-bus-width = 8;
ti,nand-ecc-opt = bch8;
- gpmc,device-nand = true;
gpmc,device-width = 1;
gpmc,sync-clk-ps = 0;
gpmc,cs-on-ns = 0;
@@ -296,7 +295,7 @@
#address-cells = 1;
#size-cells = 1;
- elm_id = elm;
+ ti,elm-id = elm;
/* MTD partition table */
partition@0 {
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
index e2249bc..501f863 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -105,7 +105,7 @@
reg = 1 0 0x0800;
nand-bus-width = 8;
- ti,nand-ecc-opt = sw;
+ ti,nand-ecc-opt = ham1;
gpmc,cs-on-ns = 0;
gpmc,cs-rd-off-ns = 36;
gpmc,cs-wr-off-ns = 36;
--
1.8.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 v8 6/6] mtd: nand: omap: updated devm_xx for all resource allocation and free calls
Managed Device Resource or devm_xx calls takes care of automatic freeing
of the resource in case of:
- failure during driver probe
- failure during resource allocation
- detaching or unloading of driver module (rmmod)
Reference: Documentation/driver-model/devres.txt
Though OMAP NAND driver handles freeing of resource allocation in most of
the cases, but using devm_xx provides more clean and effortless approach
to handle all such cases.
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/omap2.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index a783dae..0f2b0d1 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1658,7 +1658,8 @@ static int omap_nand_probe(struct platform_device *pdev)
return -ENODEV;
}
- info = kzalloc(sizeof(struct omap_nand_info), GFP_KERNEL);
+ info = devm_kzalloc(pdev-dev, sizeof(struct omap_nand_info),
+ GFP_KERNEL);
if (!info)
return -ENOMEM;
@@ -1690,13 +1691,14 @@ static int omap_nand_probe(struct platform_device *pdev)
info-phys_base = res-start;
info-mem_size = resource_size(res);
- if (!request_mem_region(info-phys_base, info-mem_size,
- pdev-dev.driver-name)) {
+ if (!devm_request_mem_region(pdev-dev, info-phys_base,
+ info-mem_size, pdev-dev.driver-name)) {
err = -EBUSY;
goto out_free_info;
}
- info-nand.IO_ADDR_R = ioremap(info-phys_base, info-mem_size);
+ info-nand.IO_ADDR_R = devm_ioremap(pdev-dev, info-phys_base,
+ info-mem_size);
if (!info-nand.IO_ADDR_R) {
err = -ENOMEM;
goto out_release_mem_region;
@@ -1799,8 +1801,9 @@ static int omap_nand_probe(struct platform_device *pdev)
err = -ENODEV;
goto out_release_mem_region;
}
- err = request_irq(info-gpmc_irq_fifo, omap_nand_irq,
- IRQF_SHARED, gpmc-nand-fifo, info);
+ err = devm_request_irq(pdev-dev, info-gpmc_irq_fifo,
+ omap_nand_irq, IRQF_SHARED,
+ gpmc-nand-fifo, info);
if (err) {
dev_err(pdev-dev, requesting irq(%d) error:%d,
info-gpmc_irq_fifo, err);
@@ -1814,8 +1817,9 @@ static int omap_nand_probe(struct platform_device *pdev)
err = -ENODEV;
goto out_release_mem_region;
}
- err = request_irq(info-gpmc_irq_count, omap_nand_irq,
- IRQF_SHARED, gpmc-nand-count, info);
+ err = devm_request_irq(pdev-dev, info-gpmc_irq_count,
+ omap_nand_irq, IRQF_SHARED,
+ gpmc-nand-count, info);
if (err) {
dev_err(pdev-dev, requesting irq(%d) error:%d,
info-gpmc_irq_count, err);
@@ -2031,10 +2035,10 @@ out_release_mem_region:
if (info-dma)
dma_release_channel(info-dma);
if (info-gpmc_irq_count 0)
- free_irq(info-gpmc_irq_count, info);
+ devm_free_irq(pdev-dev, info-gpmc_irq_count, info);
if (info-gpmc_irq_fifo 0)
- free_irq(info-gpmc_irq_fifo, info);
- release_mem_region(info-phys_base, info-mem_size);
+ devm_free_irq(pdev-dev, info-gpmc_irq_fifo, info);
+ devm_release_mem_region(pdev-dev, info-phys_base, info-mem_size);
out_free_info:
#ifdef CONFIG_MTD_NAND_ECC_BCH
if (info-nand.ecc.priv) {
@@ -2042,7 +2046,7 @@ out_free_info:
info-nand.ecc.priv = NULL;
}
#endif
- kfree(info);
+ devm_kfree(pdev-dev, info);
return err;
}
@@ -2062,15 +2066,15 @@ static int omap_nand_remove(struct platform_device
*pdev)
dma_release_channel(info-dma);
if (info-gpmc_irq_count 0)
- free_irq(info-gpmc_irq_count, info);
+ devm_free_irq(pdev-dev, info-gpmc_irq_count, info);
if (info-gpmc_irq_fifo 0)
- free_irq(info-gpmc_irq_fifo, info);
+ devm_free_irq(pdev-dev, info-gpmc_irq_fifo, info);
/* Release NAND device, its internal structures and partitions */
nand_release(info-mtd);
- iounmap(info-nand.IO_ADDR_R);
- release_mem_region(info-phys_base, info-mem_size);
- kfree(info);
+ devm_iounmap(pdev-dev, info-nand.IO_ADDR_R);
+ devm_release_mem_region(pdev-dev, info-phys_base, info-mem_size);
+ devm_kfree(pdev-dev,
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
On 10/11/2013 11:49 AM, Roger Quadros wrote: On 10/10/2013 07:00 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [131010 06:32]: I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts while the system is still running and only the EHCI controller is runtime suspended. It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain whenever the pad wakeup_enable bit is changed. Sounds like this is on omap3? Have you tried calling pcs_soc-rearm() in the pcs_irq_handle() like the comments there suggest? At least for me that keeps the wake-up interrupts continuously running on omap3 instead of just idle modes. Yes it is on OMAP3. I haven't tried with pcs_soc-rearm(). I will give it a try and let you know. Now on omap4, I've noticed the wake up interrupts are on all the time based on tests with the serial driver. I think pcs_irq_set_wake() is where need to control system wakeup behaviour for the irq. This is where we should be able to change WAKEUP_EN bit of the pad to enable/disable system wakeup for that pad and also call _reconfigure_io_chain(). Well the irq_set_wake() should only be needed for suspend and resume. For runtime PM the wake-events should be always enabled by default as pointed out by Alan Stern a while back. Right, but we need to update the WAKEUP_EN bit in the pad control register for that to work, no?. This is something we are not doing in the driver. OK sorry, just figured out that we are doing it indeed in pcs_irq_set(). Wasn't able to test it yet with USB. But I don't see any issues except that pcs_soc-rearm() needs to be called from pcs_irq_set() instead of from pcs_irq_unmask(). After that you can add my Reviewed-by: Roger Quadros rog...@ti.com 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 2/2] ARM: dts: omap5: Add dr_mode for dwc3
Hi, On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote: From: George Cherian george.cher...@ti.com Added dr_mode property in dwc3 and set its default mode to device. If there is a specific reason why this is not set to otg, we need to explain it here. AFAIK the port is meant to be used as OTG port. Signed-off-by: George Cherian george.cher...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/boot/dts/omap5.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 6d0a1d5..ef598af 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -652,6 +652,7 @@ reg = 0x4a03 0x1; interrupts = GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH; usb-phy = usb2_phy, usb3_phy; + dr_mode = peripheral; tx-fifo-resize; }; }; 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 3/7] drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
On 09/16/2013 10:37 AM, Roger Quadros wrote:
On 09/16/2013 06:01 AM, Kishon Vijay Abraham I wrote:
On Thursday 12 September 2013 04:49 PM, Roger Quadros wrote:
Hi Kishon,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted omap-usb3 PHY driver to Generic PHY Framework and moved
phy-omap-usb3
driver in drivers/usb/phy to drivers/phy and also renamed the file to
phy-omap-pipe3 since this same driver will be used for SATA PHY and
PCIE PHY.
I would suggest to split the renaming and PHY adaptation into 2 separate
patches.
Alright.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt |5 +-
drivers/phy/Kconfig| 10 +
drivers/phy/Makefile |1 +
.../phy/phy-omap-usb3.c = phy/phy-omap-pipe3.c} | 206
+++-
how about naming it to phy-ti-pipe3.c as it is used on OMAP as well as
non-OMAP e.g. DRA7.
hmm.. I thought it would be consistent with other PHY drivers
(phy-omap-usb2). Moreover DRA7 is OMAP based platform ;-) Maybe we should
reserve that for later?
OK. Up to you.
drivers/usb/phy/Kconfig| 11 --
drivers/usb/phy/Makefile |1 -
include/linux/phy/omap_pipe3.h | 52 +
7 files changed, 177 insertions(+), 109 deletions(-)
rename drivers/{usb/phy/phy-omap-usb3.c = phy/phy-omap-pipe3.c} (57%)
create mode 100644 include/linux/phy/omap_pipe3.h
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index c0245c8..36bdb17 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -21,10 +21,11 @@ usb2phy@4a0ad080 {
#phy-cells = 0;
};
-OMAP USB3 PHY
+OMAP PIPE3 PHY
Required properties:
- - compatible: Should be ti,omap-usb3
+ - compatible: Should be ti,omap-usb3, ti,omap-pipe3, ti,omap-sata
+ or ti,omap-pcie
- reg : Address and length of the register set for the device.
- reg-names: The names of the register addresses corresponding to the
registers
filled in reg.
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ac239ac..5c2e7a0 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -27,6 +27,16 @@ config OMAP_USB2
The USB OTG controller communicates with the comparator using this
driver.
+config OMAP_PIPE3
+tristate OMAP PIPE3 PHY Driver
+select GENERIC_PHY
+select OMAP_CONTROL_USB
how about
depends on OMAP_CONTROL_USB
From whatever I could make out from comments of Greg in my Generic PHY
Framework, it's better to do a select of dependent modules instead of
depends on.
You can use select, provided the item you are selecting doesn't depend on
anything else.
As OMAP_CONTROL_USB depends on ARCH_OMAP2PLUS, your configuration will fail
if a user enables
OMAP_PIPE3 on non OMAP configuration.
Further, in this case since it is OMAP related driver, there is no point in
showing/building it
if OMAP platform is not selected, so you at least need [depends on
ARCH_OMAP2PLUS] to fix
both issue I mentioned.
Also, if this is TI/OMAP it might as well depend on ARCH_OMAP.
+help
+ Enable this to support the PIPE3 PHY that is part of SOC. This
worth mentioning TI OMAP/DRA SoCs.
right.
+ driver takes care of all the PHY functionality apart from
comparator.
+ This driver interacts with the OMAP Control PHY Driver to power
+ on/off the PHY.
+
config TWL4030_USB
tristate TWL4030 USB Transceiver Driver
depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 0dd8a98..48bf9f2 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,4 +4,5 @@
obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
+obj-$(CONFIG_OMAP_PIPE3)+= phy-omap-pipe3.o
obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/phy/phy-omap-pipe3.c
similarity index 57%
rename from drivers/usb/phy/phy-omap-usb3.c
rename to drivers/phy/phy-omap-pipe3.c
index 4004f82..ee9a901 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/phy/phy-omap-pipe3.c
@@ -1,5 +1,5 @@
/*
- * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
+ * omap-pipe3 - PHY driver for SATA, USB and PCIE in OMAP platforms
*
* Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
* This program is free software; you can redistribute it and/or modify
@@ -19,7 +19,8 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
-#include linux/usb/omap_usb.h
+#include linux/phy/omap_pipe3.h
+#include linux/phy/phy.h
#include linux/of.h
#include
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Hi,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
How about adding
+ if (dwc-usb2_phy)
+ usb_phy_init(dwc-usb2_phy);
+ if (dwc-usb3_phy)
+ usb_phy_init(dwc-usb3_phy);
both usb phy and generic phy shouldn't be present together.
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
here as well
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK (16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
better to add
+ /* Don't use USB PHY if generic PHY was found */
+ dwc-usb2_phy = dwc-usb3_phy = NULL;
+ } else {
not required as we've used kzalloc for dwc.
+ dwc-usb2_generic_phy = NULL;
+ dwc-usb3_generic_phy = NULL;
+ }
+
/* default to superspeed if no maximum_speed passed */
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
@@ -450,6 +478,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc-usb2_phy)
usb_phy_set_suspend(dwc-usb2_phy, 0);
if (dwc-usb3_phy)
usb_phy_set_suspend(dwc-usb3_phy, 0);
+ if (dwc-usb2_generic_phy)
+ phy_power_on(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_on(dwc-usb3_generic_phy);
+
spin_lock_init(dwc-lock);
platform_set_drvdata(pdev, dwc);
@@ -576,6 +609,11 @@
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
* Roger Quadros rog...@ti.com [131011 07:07]: On 10/11/2013 11:49 AM, Roger Quadros wrote: On 10/10/2013 07:00 PM, Tony Lindgren wrote: Well the irq_set_wake() should only be needed for suspend and resume. For runtime PM the wake-events should be always enabled by default as pointed out by Alan Stern a while back. Right, but we need to update the WAKEUP_EN bit in the pad control register for that to work, no?. This is something we are not doing in the driver. OK sorry, just figured out that we are doing it indeed in pcs_irq_set(). Wasn't able to test it yet with USB. But I don't see any issues except that pcs_soc-rearm() needs to be called from pcs_irq_set() instead of from pcs_irq_unmask(). Hmm that sounds like a different behaviour compared to what I'm seeing on omap3. Care to send a little fix on top of these patches so I can test it with my set up too? It seems that the only difference would be that we're calling rearm() after both masking and unmasking, which seemed unnecessary to me earlier. After that you can add my Reviewed-by: Roger Quadros rog...@ti.com Thanks, for testing, sorry I already pushed them out after Kevin ran his PM tests on them. 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/6] pinctrl: single: Add support for wake-up interrupts
* Roger Quadros rog...@ti.com [131011 02:04]: On 10/11/2013 11:00 AM, Linus Walleij wrote: On Thu, Oct 10, 2013 at 6:20 PM, Tony Lindgren t...@atomide.com wrote: * Linus Walleij linus.wall...@linaro.org [131010 09:19]: On Thu, Oct 10, 2013 at 6:00 PM, Tony Lindgren t...@atomide.com wrote: * Roger Quadros rog...@ti.com [131010 06:32]: I tried testing this with the USB EHCI driver, but I'm not getting wake up interrupts while the system is still running and only the EHCI controller is runtime suspended. It seems we need to somehow call _reconfigure_io_chain() to update the daisy chain whenever the pad wakeup_enable bit is changed. Sounds like this is on omap3? Have you tried calling pcs_soc-rearm() in the pcs_irq_handle() like the comments there suggest? At least for me that keeps the wake-up interrupts continuously running on omap3 instead of just idle modes. If the rearm() function is calling this _reconfigure_io_chain my comments on the fact that this is something that should be handled by the pin control driver still apply I think Yes, except that the reconfigure_io_chain registers are in the PRM module, not in the SCM module where the pinctrl registers are.. And that shared PRM interrupt is used mostly for the internal domain wake-ups, so we should keep that in the PRM driver. That depends. One-iorange-equals-one-driver is a fallacy, especially given that MFD for memory-mapped things exist for a reason. +1 Another place I faced a similar problem was the OMAP control module, which contains registers for a number of different non related peripherals. (e.g. PHY for USB, SATA, Display clock, etc) Guys, we really need to keep the register access between hardware modules under control because the hardware blocks can live separate life from clocking and power state point of view. Regmap could be probably used for the register access across various hardware modules in a controlled way that is also aware of the clocking and PM state of the hardware modules in question. As long as it's done sanely, I'm OK with that. But for any other kind of random direct register tinkering between hardware modules, that's a no no. What the pin control driver should do is control the pins. Whether the registers are spread out in the entire IO-memory does not matter. We did have one system which placed the IO-muxing together with each peripheral (!) and I did still want that to be handled by a single pinctrl driver picking out windows to all these IO-ranges. Things like the PRM which has (my guess) a gazillion registers related to its deep-core SoC stuff should be handled by things like drivers/mfd/syscon.c, which means it is dead simple for some other driver using just this one register in that range to get a handle at it and poke it using syscon_node_to_regmap() (just derference an ampersand ref) syscon_regmap_lookup_by_compatible() (use a compatible string) all returning a regmap * that you can use to poke these registers. The register handling is fine. But how do we deal with resource handling? e.g. the block that has the deep-core registers might need to be clocked or powered before the registers can be accessed. Right, that's the key issue here. The register access would have to be conditional based on the hardware modules PM state. Otherwise we'll have hard to trace hangs and oopses. 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/6] pinctrl: single: Add support for wake-up interrupts
On Friday 11 October 2013 09:06 PM, Tony Lindgren wrote: What the pin control driver should do is control the pins. Whether the registers are spread out in the entire IO-memory does not matter. We did have one system which placed the IO-muxing together with each peripheral (!) and I did still want that to be handled by a single pinctrl driver picking out windows to all these IO-ranges. Things like the PRM which has (my guess) a gazillion registers related to its deep-core SoC stuff should be handled by things like drivers/mfd/syscon.c, which means it is dead simple for some other driver using just this one register in that range to get a handle at it and poke it using syscon_node_to_regmap() (just derference an ampersand ref) syscon_regmap_lookup_by_compatible() (use a compatible string) all returning a regmap * that you can use to poke these registers. The register handling is fine. But how do we deal with resource handling? e.g. the block that has the deep-core registers might need to be clocked or powered before the registers can be accessed. Right, that's the key issue here. The register access would have to be conditional based on the hardware modules PM state. Otherwise we'll have hard to trace hangs and oopses. Hi Tony, How are the clocks/power state currently handled in case of omap4_pmx_core, omap4_pmx_wkup register access via pinctrl-single ? Thanks and Regards, Balaji T K -- 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/6] pinctrl: single: Add support for wake-up interrupts
* Linus Walleij linus.wall...@linaro.org [131011 03:40]: On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros rog...@ti.com wrote: The register handling is fine. But how do we deal with resource handling? e.g. the block that has the deep-core registers might need to be clocked or powered before the registers can be accessed. Yeah I saw this in the code there. In this case it seems syscon-type regmap access can be used to read/write the registers, so maybe the pin controller also need to get a handle on some clock etc? Uhh, let's not go there.. The resource availability needs to be handled transparently in regmap code and the reg provider hardware module driver using runtime PM. The general idea is however that large monolitic drivers for a certain IO-range such as arch/arm/mach-omap2/prm3xxx.c doesn't scale - we saw this with the Ux500 PRCMU driver in mfd/* to the point that our patches to extend it were NACK:ed until we refactor it. This stuff in mach-omap2 is in the same bad design pattern, and need to get out of it. The approach chosen for the Ux500 PRCMU was to distribute out the driver into the places where it's actually used, like the clock driver etc. The accessor functions to do some stuff over in the PRCMU was just adding a layer of cruft. Yes I'm all in favor of having a minimal PRM core driver that manages resources and provides register access services in a controlled way to it's client drivers. As long as the emphasis is in a controlled way. 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/6] pinctrl: single: Add support for wake-up interrupts
* Balaji T K balaj...@ti.com [131011 08:51]: On Friday 11 October 2013 09:06 PM, Tony Lindgren wrote: What the pin control driver should do is control the pins. Whether the registers are spread out in the entire IO-memory does not matter. We did have one system which placed the IO-muxing together with each peripheral (!) and I did still want that to be handled by a single pinctrl driver picking out windows to all these IO-ranges. Things like the PRM which has (my guess) a gazillion registers related to its deep-core SoC stuff should be handled by things like drivers/mfd/syscon.c, which means it is dead simple for some other driver using just this one register in that range to get a handle at it and poke it using syscon_node_to_regmap() (just derference an ampersand ref) syscon_regmap_lookup_by_compatible() (use a compatible string) all returning a regmap * that you can use to poke these registers. The register handling is fine. But how do we deal with resource handling? e.g. the block that has the deep-core registers might need to be clocked or powered before the registers can be accessed. Right, that's the key issue here. The register access would have to be conditional based on the hardware modules PM state. Otherwise we'll have hard to trace hangs and oopses. Hi Tony, How are the clocks/power state currently handled in case of omap4_pmx_core, omap4_pmx_wkup register access via pinctrl-single ? It's currently always on during runtime and managed in for the whole SCM by mach-omap2/control.c. Then there's a separate SCM register that triggers the save and restore of the padconf registers in hardware for off-idle along with other SCM related things, see the *_control_save/restore_context() functions. 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 v8 5/6] ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt
On Fri, Oct 11, 2013 at 07:06:42PM +0530, Pekon Gupta wrote:
Updated DTS to replace deprecated binding with newer values
Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt
Signed-off-by: Pekon Gupta pe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 3 +--
arch/arm/boot/dts/omap3430-sdp.dts | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index e8ec875..1aee6ac 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -269,7 +269,6 @@
reg = 0 0 0; /* CS0, offset 0 */
nand-bus-width = 8;
ti,nand-ecc-opt = bch8;
- gpmc,device-nand = true;
gpmc,device-width = 1;
gpmc,sync-clk-ps = 0;
gpmc,cs-on-ns = 0;
@@ -296,7 +295,7 @@
#address-cells = 1;
#size-cells = 1;
- elm_id = elm;
+ ti,elm-id = elm;
/* MTD partition table */
partition@0 {
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
index e2249bc..501f863 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -105,7 +105,7 @@
reg = 1 0 0x0800;
nand-bus-width = 8;
- ti,nand-ecc-opt = sw;
+ ti,nand-ecc-opt = ham1;
gpmc,cs-on-ns = 0;
gpmc,cs-rd-off-ns = 36;
gpmc,cs-wr-off-ns = 36;
--
1.8.1
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v8 2/6] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
On Fri, Oct 11, 2013 at 07:06:39PM +0530, Pekon Gupta wrote:
OMAP NAND driver support multiple ECC scheme, which can used in following
different flavours, depending on in-build Hardware engines supported by SoC.
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAM1_CODE_HW |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
|(requires CONFIG_MTD_NAND_ECC_BCH) | | |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
|(requires CONFIG_MTD_NAND_OMAP_BCH | | |
| ti,elm-id in DT) | | |
+---+---+---+
To optimize footprint of omap2-nand driver, selection of some ECC schemes
also require enabling following Kconfigs, in addition to setting appropriate
DT bindings
- Kconfig:CONFIG_MTD_NAND_ECC_BCHerror detection done in software
- Kconfig:CONFIG_MTD_NAND_OMAP_BCH error detection done by h/w engine
DT binding updates in this patch are:
- ti,elm-id: replaces elm_id
- ti,nand-ecc-opts: supported values ham1, bch4, and bch8
selection of h/w or s/w implementation depends on ti,elm-id
Signed-off-by: Pekon Gupta pe...@ti.com
since this maintains backwards compatibility, I think it should be
alright to apply
Reviewed-by: Felipe Balbi ba...@ti.com
---
.../devicetree/bindings/mtd/gpmc-nand.txt | 8 +++-
arch/arm/mach-omap2/gpmc.c | 45
--
include/linux/platform_data/mtd-nand-omap2.h | 14 +--
3 files changed, 50 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index 25ee232..5e1f31b 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -36,8 +36,12 @@ Optional properties:
prefetch-dma Prefetch enabled sDMA mode
prefetch-irq Prefetch enabled irq mode
- - elm_id: Specifies elm device node. This is required to support BCH
- error correction using ELM module.
+ - elm_id: deprecated use ti,elm-id instead
+ - ti,elm-id:Specifies phandle of the ELM devicetree node.
+ ELM is an on-chip hardware engine on TI SoC which is used for
+ locating ECC errors for BCHx algorithms. SoC devices which have
+ ELM hardware engines should specify this device node in .dtsi
+ Using ELM for ECC error correction frees some CPU cycles.
For inline partiton table parsing (optional):
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index c9fb353..9473c9f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1341,12 +1341,6 @@ static void __maybe_unused gpmc_read_timings_dt(struct
device_node *np,
#ifdef CONFIG_MTD_NAND
-static const char * const nand_ecc_opts[] = {
- [OMAP_ECC_HAM1_CODE_HW] = ham1,
- [OMAP_ECC_BCH4_CODE_HW] = bch4,
- [OMAP_ECC_BCH8_CODE_HW] = bch8,
-};
-
static const char * const nand_xfer_types[] = {
[NAND_OMAP_PREFETCH_POLLED] = prefetch-polled,
[NAND_OMAP_POLLED] = polled,
@@ -1376,12 +1370,39 @@ static int gpmc_probe_nand_child(struct
platform_device *pdev,
gpmc_nand_data-cs = val;
gpmc_nand_data-of_node = child;
- if (!of_property_read_string(child, ti,nand-ecc-opt, s))
- for (val = 0; val ARRAY_SIZE(nand_ecc_opts); val++)
- if (!strcasecmp(s, nand_ecc_opts[val])) {
- gpmc_nand_data-ecc_opt = val;
- break;
- }
+ /* Detect availability of ELM module */
+ gpmc_nand_data-elm_of_node = of_parse_phandle(child, ti,elm-id, 0);
+ if (gpmc_nand_data-elm_of_node == NULL)
+ gpmc_nand_data-elm_of_node =
+ of_parse_phandle(child, elm_id, 0);
+ if (gpmc_nand_data-elm_of_node == NULL)
+ pr_warn(%s: ti,elm-id property not found\n, __func__);
+
+ /* select NAND ecc-opt */
+ if (of_property_read_string(child, ti,nand-ecc-opt, s)) {
+ pr_err(%s: ti,nand-ecc-opt not found\n, __func__);
+ return -ENODEV;
+ }
+ if (!strcmp(s, ham1) || !strcmp(s, sw) ||
+ !strcmp(s, hw) || !strcmp(s,
Re: [PATCH v8 4/6] mtd:nand:omap2: updated support for BCH4 ECC scheme
On Fri, Oct 11, 2013 at 07:06:41PM +0530, Pekon Gupta wrote:
This patch adds following two flavours of BCH4 ECC scheme in omap2-nand driver
- OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
- uses GPMC H/W engine for calculating ECC.
- uses software library (lib/bch.h nand_bch.h) for error correction.
- OMAP_ECC_BCH4_CODE_HW
- uses GPMC H/W engine for calculating ECC.
- uses ELM H/W engine for error correction.
With this patch omap2-nand driver supports following ECC schemes:
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAM1_CODE_HW |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)|
|OMAP_ECC_BCH4_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)|
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
Important:
- Selection of OMAP_ECC_BCHx_CODE_HW_DETECTION_SW requires,
Kconfig: CONFIG_MTD_NAND_ECC_BCH: enables S/W based BCH ECC algorithm.
- Selection of OMAP_ECC_BCHx_CODE_HW requires,
Kconfig: CONFIG_MTD_NAND_OMAP_BCH: enables ELM H/W module.
Signed-off-by: Pekon Gupta pe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mtd/nand/Kconfig | 30 ++-
drivers/mtd/nand/omap2.c | 134
+--
2 files changed, 63 insertions(+), 101 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index d885298..5836039 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -96,35 +96,13 @@ config MTD_NAND_OMAP2
config MTD_NAND_OMAP_BCH
depends on MTD_NAND MTD_NAND_OMAP2 ARCH_OMAP3
- tristate Enable support for hardware BCH error correction
+ tristate Support hardware based BCH error correction
default n
select BCH
- select BCH_CONST_PARAMS
help
- Support for hardware BCH error correction.
-
-choice
- prompt BCH error correction capability
- depends on MTD_NAND_OMAP_BCH
-
-config MTD_NAND_OMAP_BCH8
- bool 8 bits / 512 bytes (recommended)
- help
- Support correcting up to 8 bitflips per 512-byte block.
- This will use 13 bytes of spare area per 512 bytes of page data.
- This is the recommended mode, as 4-bit mode does not work
- on some OMAP3 revisions, due to a hardware bug.
-
-config MTD_NAND_OMAP_BCH4
- bool 4 bits / 512 bytes
- help
- Support correcting up to 4 bitflips per 512-byte block.
- This will use 7 bytes of spare area per 512 bytes of page data.
- Note that this mode does not work on some OMAP3 revisions, due to a
- hardware bug. Please check your OMAP datasheet before selecting this
- mode.
-
-endchoice
+ Some devices have built-in ELM hardware engine, which can be used to
+ locate and correct errors when using BCH ECC scheme. This enables the
+ driver support for same.
if MTD_NAND_OMAP_BCH
config BCH_CONST_M
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index fb96251..a783dae 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -27,6 +27,7 @@
#ifdef CONFIG_MTD_NAND_ECC_BCH
#include linux/bch.h
+#include linux/mtd/nand_bch.h
#endif
#ifdef CONFIG_MTD_NAND_OMAP_BCH
#include linux/platform_data/elm.h
@@ -144,7 +145,6 @@
#define BCH_ECC_SIZE10x20/* ecc_size1 = 32 */
#define BADBLOCK_MARKER_LENGTH 2
-#define OMAP_ECC_BCH8_POLYNOMIAL 0x201b
#ifdef CONFIG_MTD_NAND_OMAP_BCH
static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe,
0xcc,
@@ -188,7 +188,6 @@ struct omap_nand_info {
int buf_len;
struct gpmc_nand_regs reg;
/* fields specific for BCHx_HW ECC scheme */
- struct bch_control *bch;
boolis_elm_used;
struct device *elm_dev;
struct device_node *of_node;
@@ -1522,43 +1521,7 @@ static int omap_elm_correct_data(struct mtd_info *mtd,
u_char *data,
return stat;
}
-#endif /* CONFIG_MTD_NAND_OMAP_BCH */
-#ifdef CONFIG_MTD_NAND_ECC_BCH
-/**
- * omap3_correct_data_bch - Decode received data and correct errors
- * @mtd: MTD device structure
- * @data: page data
- * @read_ecc: ecc read from nand flash
- * @calc_ecc: ecc read from HW ECC registers
- */
-static int omap3_correct_data_bch(struct
Re: [PATCH v8 3/6] mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe
On Fri, Oct 11, 2013 at 07:06:40PM +0530, Pekon Gupta wrote:
OMAP NAND driver support multiple ECC scheme, which can used in following
different flavours, depending on in-build Hardware engines supported by SoC.
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAM1_CODE_HW |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
|(requires CONFIG_MTD_NAND_ECC_BCH) | | |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
|(requires CONFIG_MTD_NAND_OMAP_BCH | | |
| ti,elm-id in DT) | | |
+---+---+---+
To optimize footprint of omap2-nand driver, selection of some ECC schemes
also require enabling following Kconfigs, in addition to setting appropriate
DT bindings
- Kconfig:CONFIG_MTD_NAND_ECC_BCHenables S/W based BCH ECC algorithm
- Kconfig:CONFIG_MTD_NAND_OMAP_BCH enables H/W based BCH ECC algorithm
This patch
- separates the configurations code for each ECC schemes
- fixes dependency issues based on Kconfig options
- updates ELM device detection in is_elm_present()
- cleans redundant code
Signed-off-by: Pekon Gupta pe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mtd/nand/omap2.c | 450
+++
1 file changed, 220 insertions(+), 230 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 8d521aa..fb96251 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -25,8 +25,10 @@
#include linux/of.h
#include linux/of_device.h
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
+#ifdef CONFIG_MTD_NAND_ECC_BCH
#include linux/bch.h
+#endif
+#ifdef CONFIG_MTD_NAND_OMAP_BCH
#include linux/platform_data/elm.h
#endif
@@ -141,6 +143,9 @@
#define BCH_ECC_SIZE00x0 /* ecc_size0 = 0, no oob
protection */
#define BCH_ECC_SIZE10x20/* ecc_size1 = 32 */
+#define BADBLOCK_MARKER_LENGTH 2
+#define OMAP_ECC_BCH8_POLYNOMIAL 0x201b
+
#ifdef CONFIG_MTD_NAND_OMAP_BCH
static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe,
0xcc,
0xac, 0x6b, 0xff, 0x99, 0x7b};
@@ -182,14 +187,11 @@ struct omap_nand_info {
u_char *buf;
int buf_len;
struct gpmc_nand_regs reg;
-
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
- struct bch_control *bch;
- struct nand_ecclayout ecclayout;
+ /* fields specific for BCHx_HW ECC scheme */
+ struct bch_control *bch;
boolis_elm_used;
struct device *elm_dev;
struct device_node *of_node;
-#endif
};
/**
@@ -1058,8 +1060,7 @@ static int omap_dev_ready(struct mtd_info *mtd)
}
}
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
-
+#if defined(CONFIG_MTD_NAND_ECC_BCH) || defined(CONFIG_MTD_NAND_OMAP_BCH)
/**
* omap3_enable_hwecc_bch - Program OMAP3 GPMC to perform BCH ECC correction
* @mtd: MTD device structure
@@ -1140,7 +1141,9 @@ static void omap3_enable_hwecc_bch(struct mtd_info
*mtd, int mode)
/* Clear ecc and enable bits */
writel(ECCCLEAR | ECC1, info-reg.gpmc_ecc_control);
}
+#endif
+#ifdef CONFIG_MTD_NAND_ECC_BCH
/**
* omap3_calculate_ecc_bch4 - Generate 7 bytes of ECC bytes
* @mtd: MTD device structure
@@ -1225,7 +1228,9 @@ static int omap3_calculate_ecc_bch8(struct mtd_info
*mtd, const u_char *dat,
return 0;
}
+#endif /* CONFIG_MTD_NAND_ECC_BCH */
+#ifdef CONFIG_MTD_NAND_OMAP_BCH
/**
* omap3_calculate_ecc_bch - Generate bytes of ECC bytes
* @mtd: MTD device structure
@@ -1517,7 +1522,9 @@ static int omap_elm_correct_data(struct mtd_info *mtd,
u_char *data,
return stat;
}
+#endif /* CONFIG_MTD_NAND_OMAP_BCH */
+#ifdef CONFIG_MTD_NAND_ECC_BCH
/**
* omap3_correct_data_bch - Decode received data and correct errors
* @mtd: MTD device structure
@@ -1549,7 +1556,9 @@ static int omap3_correct_data_bch(struct mtd_info *mtd,
u_char *data,
}
return count;
}
+#endif /* CONFIG_MTD_NAND_ECC_BCH */
+#ifdef CONFIG_MTD_NAND_OMAP_BCH
/**
* omap_write_page_bch - BCH ecc based write page function for entire page
* @mtd: mtd info structure
@@ -1637,197 +1646,68 @@ static int omap_read_page_bch(struct mtd_info *mtd,
struct nand_chip
Re: [PATCH v8 1/6] mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes
On Fri, Oct 11, 2013 at 07:06:38PM +0530, Pekon Gupta wrote:
OMAP NAND driver currently supports multiple flavours of 1-bit Hamming
ecc-scheme, like:
- OMAP_ECC_HAMMING_CODE_DEFAULT
1-bit hamming ecc code using software library
- OMAP_ECC_HAMMING_CODE_HW
1-bit hamming ecc-code using GPMC h/w engine
- OMAP_ECC_HAMMING_CODE_HW_ROMCODE
1-bit hamming ecc-code using GPMC h/w engin with ecc-layout compatible
to ROM code.
This patch combines above multiple ecc-schemes into single implementation:
- OMAP_ECC_HAM1_CODE_HW
1-bit hamming ecc-code using GPMC h/w engine with ROM-code compatible
ecc-layout.
Signed-off-by: Pekon Gupta pe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 8
arch/arm/mach-omap2/board-flash.c | 2 +-
arch/arm/mach-omap2/gpmc.c | 4 +---
drivers/mtd/nand/omap2.c| 9 +++--
include/linux/platform_data/mtd-nand-omap2.h| 6 +-
5 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index df338cb..25ee232 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -22,10 +22,10 @@ Optional properties:
width of 8 is assumed.
- ti,nand-ecc-opt: A string setting the ECC layout to use. One of:
-
- swSoftware method (default)
- hwHardware method
- hw-romcodegpmc hamming mode method romcode layout
+ swdeprecated use ham1 instead
+ hwdeprecated use ham1 instead
+ hw-romcodedeprecated use ham1 instead
+ ham1 1-bit Hamming ecc code
bch4 4-bit BCH ecc code
bch8 8-bit BCH ecc code
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index fc20a61..ac82512 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -142,7 +142,7 @@ __init board_nand_init(struct mtd_partition *nand_parts,
u8 nr_parts, u8 cs,
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
- board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
+ board_nand_data.ecc_opt = OMAP_ECC_BCH8_CODE_HW;
gpmc_nand_init(board_nand_data, gpmc_t);
}
#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 579697a..c9fb353 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1342,9 +1342,7 @@ static void __maybe_unused gpmc_read_timings_dt(struct
device_node *np,
#ifdef CONFIG_MTD_NAND
static const char * const nand_ecc_opts[] = {
- [OMAP_ECC_HAMMING_CODE_DEFAULT] = sw,
- [OMAP_ECC_HAMMING_CODE_HW] = hw,
- [OMAP_ECC_HAMMING_CODE_HW_ROMCODE] = hw-romcode,
+ [OMAP_ECC_HAM1_CODE_HW] = ham1,
[OMAP_ECC_BCH4_CODE_HW] = bch4,
[OMAP_ECC_BCH8_CODE_HW] = bch8,
};
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 4ecf0e5..8d521aa 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1993,10 +1993,7 @@ static int omap_nand_probe(struct platform_device
*pdev)
}
/* select the ecc type */
- if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_DEFAULT)
- info-nand.ecc.mode = NAND_ECC_SOFT;
- else if ((pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW) ||
- (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE)) {
+ if (pdata-ecc_opt == OMAP_ECC_HAM1_CODE_HW) {
info-nand.ecc.bytes= 3;
info-nand.ecc.size = 512;
info-nand.ecc.strength = 1;
@@ -2025,7 +2022,7 @@ static int omap_nand_probe(struct platform_device *pdev)
}
/* rom code layout */
- if (pdata-ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE) {
+ if (pdata-ecc_opt == OMAP_ECC_HAM1_CODE_HW) {
if (info-nand.options NAND_BUSWIDTH_16)
offset = 2;
@@ -2033,7 +2030,7 @@ static int omap_nand_probe(struct platform_device *pdev)
offset = 1;
info-nand.badblock_pattern = bb_descrip_flashbased;
}
- omap_oobinfo.eccbytes = 3 * (info-mtd.oobsize/16);
+ omap_oobinfo.eccbytes = 3 * (info-mtd.writesize / 512);
for (i = 0; i omap_oobinfo.eccbytes; i++)
omap_oobinfo.eccpos[i] = i+offset;
diff --git a/include/linux/platform_data/mtd-nand-omap2.h
Re: [PATCH v8 6/6] mtd: nand: omap: updated devm_xx for all resource allocation and free calls
On Fri, Oct 11, 2013 at 07:06:43PM +0530, Pekon Gupta wrote:
Managed Device Resource or devm_xx calls takes care of automatic freeing
of the resource in case of:
- failure during driver probe
- failure during resource allocation
- detaching or unloading of driver module (rmmod)
Reference: Documentation/driver-model/devres.txt
Though OMAP NAND driver handles freeing of resource allocation in most of
the cases, but using devm_xx provides more clean and effortless approach
to handle all such cases.
Signed-off-by: Pekon Gupta pe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/mtd/nand/omap2.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index a783dae..0f2b0d1 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1658,7 +1658,8 @@ static int omap_nand_probe(struct platform_device *pdev)
return -ENODEV;
}
- info = kzalloc(sizeof(struct omap_nand_info), GFP_KERNEL);
+ info = devm_kzalloc(pdev-dev, sizeof(struct omap_nand_info),
+ GFP_KERNEL);
if (!info)
return -ENOMEM;
@@ -1690,13 +1691,14 @@ static int omap_nand_probe(struct platform_device
*pdev)
info-phys_base = res-start;
info-mem_size = resource_size(res);
- if (!request_mem_region(info-phys_base, info-mem_size,
- pdev-dev.driver-name)) {
+ if (!devm_request_mem_region(pdev-dev, info-phys_base,
+ info-mem_size, pdev-dev.driver-name)) {
err = -EBUSY;
goto out_free_info;
}
- info-nand.IO_ADDR_R = ioremap(info-phys_base, info-mem_size);
+ info-nand.IO_ADDR_R = devm_ioremap(pdev-dev, info-phys_base,
+ info-mem_size);
if (!info-nand.IO_ADDR_R) {
err = -ENOMEM;
goto out_release_mem_region;
@@ -1799,8 +1801,9 @@ static int omap_nand_probe(struct platform_device *pdev)
err = -ENODEV;
goto out_release_mem_region;
}
- err = request_irq(info-gpmc_irq_fifo, omap_nand_irq,
- IRQF_SHARED, gpmc-nand-fifo, info);
+ err = devm_request_irq(pdev-dev, info-gpmc_irq_fifo,
+ omap_nand_irq, IRQF_SHARED,
+ gpmc-nand-fifo, info);
if (err) {
dev_err(pdev-dev, requesting irq(%d) error:%d,
info-gpmc_irq_fifo, err);
@@ -1814,8 +1817,9 @@ static int omap_nand_probe(struct platform_device *pdev)
err = -ENODEV;
goto out_release_mem_region;
}
- err = request_irq(info-gpmc_irq_count, omap_nand_irq,
- IRQF_SHARED, gpmc-nand-count, info);
+ err = devm_request_irq(pdev-dev, info-gpmc_irq_count,
+ omap_nand_irq, IRQF_SHARED,
+ gpmc-nand-count, info);
if (err) {
dev_err(pdev-dev, requesting irq(%d) error:%d,
info-gpmc_irq_count, err);
@@ -2031,10 +2035,10 @@ out_release_mem_region:
if (info-dma)
dma_release_channel(info-dma);
if (info-gpmc_irq_count 0)
- free_irq(info-gpmc_irq_count, info);
+ devm_free_irq(pdev-dev, info-gpmc_irq_count, info);
if (info-gpmc_irq_fifo 0)
- free_irq(info-gpmc_irq_fifo, info);
- release_mem_region(info-phys_base, info-mem_size);
+ devm_free_irq(pdev-dev, info-gpmc_irq_fifo, info);
+ devm_release_mem_region(pdev-dev, info-phys_base, info-mem_size);
out_free_info:
#ifdef CONFIG_MTD_NAND_ECC_BCH
if (info-nand.ecc.priv) {
@@ -2042,7 +2046,7 @@ out_free_info:
info-nand.ecc.priv = NULL;
}
#endif
- kfree(info);
+ devm_kfree(pdev-dev, info);
return err;
}
@@ -2062,15 +2066,15 @@ static int omap_nand_remove(struct platform_device
*pdev)
dma_release_channel(info-dma);
if (info-gpmc_irq_count 0)
- free_irq(info-gpmc_irq_count, info);
+ devm_free_irq(pdev-dev, info-gpmc_irq_count, info);
if (info-gpmc_irq_fifo 0)
- free_irq(info-gpmc_irq_fifo, info);
+ devm_free_irq(pdev-dev, info-gpmc_irq_fifo, info);
/* Release NAND device, its internal structures and partitions */
nand_release(info-mtd);
- iounmap(info-nand.IO_ADDR_R);
- release_mem_region(info-phys_base, info-mem_size);
- kfree(info);
+ devm_iounmap(pdev-dev, info-nand.IO_ADDR_R);
+
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
On Fri, Oct 11, 2013 at 5:43 PM, Tony Lindgren t...@atomide.com wrote: * Linus Walleij linus.wall...@linaro.org [131011 03:40]: On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros rog...@ti.com wrote: The register handling is fine. But how do we deal with resource handling? e.g. the block that has the deep-core registers might need to be clocked or powered before the registers can be accessed. Yeah I saw this in the code there. In this case it seems syscon-type regmap access can be used to read/write the registers, so maybe the pin controller also need to get a handle on some clock etc? Uhh, let's not go there.. The resource availability needs to be handled transparently in regmap code and the reg provider hardware module driver using runtime PM. OK we can surely discuss this with broonie, it makes sense to have regmap be able to do its deed transparently. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: Run make savedefconfig on omap2plus_defconfig to shrink it
* Tony Lindgren t...@atomide.com [131010 17:52]: * Mugunthan V N mugunthan...@ti.com [131010 17:15]: On Thursday 10 October 2013 06:04 PM, Tony Lindgren wrote: -CONFIG_TI_DAVINCI_MDIO=y -CONFIG_TI_DAVINCI_CPDMA=y -CONFIG_TI_CPSW=y -CONFIG_AT803X_PHY=y Can you keep the above defines as AM335x EVM, Beagle bone, Beagle bone black can use ethernet with omap2plus_defconfig I think they should get automatically selected by default with make omap2plus_defconfig, I don't think make savedefconfig removes any selected features. Maybe check it though with this patch? I've confirmed these are automatically selected after doing make omap2plus_defconfig. They seem to be selected by CONFIG_TI_CPSW=y that stays in the omap2plus_defconfig after doing make save_defconfig, looks like it just moves around a bit after doing make save_defconfig. BTW, why do we get edma warnings during boot on systems with no edma like on omap4: edma-dma-engine edma-dma-engine.0: Can't allocate PaRAM dummy slot edma-dma-engine: probe of edma-dma-engine.0 failed with error -5 omap-dma-engine 4a056000.dma-controller: OMAP DMA engine driver That's just confusing. 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/6] pinctrl: single: Add support for wake-up interrupts
* Linus Walleij linus.wall...@linaro.org [131011 09:05]: On Fri, Oct 11, 2013 at 5:43 PM, Tony Lindgren t...@atomide.com wrote: * Linus Walleij linus.wall...@linaro.org [131011 03:40]: On Fri, Oct 11, 2013 at 10:56 AM, Roger Quadros rog...@ti.com wrote: The register handling is fine. But how do we deal with resource handling? e.g. the block that has the deep-core registers might need to be clocked or powered before the registers can be accessed. Yeah I saw this in the code there. In this case it seems syscon-type regmap access can be used to read/write the registers, so maybe the pin controller also need to get a handle on some clock etc? Uhh, let's not go there.. The resource availability needs to be handled transparently in regmap code and the reg provider hardware module driver using runtime PM. OK we can surely discuss this with broonie, it makes sense to have regmap be able to do its deed transparently. Yes I think so too. Sounds like we need callbacks for the runtime PM checks to the register provider driver. Hwo knows, maybe those features are there already :) 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 V6 02/15] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init
* Joel Fernandes jo...@ti.com [131010 08:31]: On 10/10/2013 10:20 AM, Joel Fernandes wrote: Adding 6 lines of identical code for every platform seems redundant, I'd just define an omap_common_late_init for all platforms for now, and then fork off for the future differences. That way we save on LOC and readability in the header as well. Your call. I see a function of that name already exists. I guess you can leave your patch as is then and not have to do this. Yeah but why not just call the common late_init function directly for the cases where we know it's never needed. If thoses will be populated in the later patches, then it's OK to add them. In any case, Nishant, can you please squash the late_init patches into a single patch and make sure it also applies on top of the omap-for-v3.13/quirk branch as there's been some changes to board-generic.c there. 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] pinctrl: single: call pcs_soc-rearm() whenever IRQ mask is changed
On OMAPs the IO ring must be rearmed each time the pad wakeup configuration is changed. So call pcs_soc-rearm() from pcs_irq_set(). Signed-off-by: Roger Quadros rog...@ti.com --- drivers/pinctrl/pinctrl-single.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c index c2aada7..1800e47 100644 --- a/drivers/pinctrl/pinctrl-single.c +++ b/drivers/pinctrl/pinctrl-single.c @@ -1604,6 +1604,9 @@ static inline void pcs_irq_set(struct pcs_soc_data *pcs_soc, pcs-write(mask, pcswi-reg); raw_spin_unlock(pcs-lock); } + + if (pcs_soc-rearm) + pcs_soc-rearm(); } /** @@ -1626,8 +1629,6 @@ static void pcs_irq_unmask(struct irq_data *d) struct pcs_soc_data *pcs_soc = irq_data_get_irq_chip_data(d); pcs_irq_set(pcs_soc, d-irq, true); - if (pcs_soc-rearm) - pcs_soc-rearm(); } /** -- 1.7.4.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 07/11] ARM: OMAP3: CM/PM: add new API for checking IVA2 idle status
OMAP3 PM code needs this functionality during the IVA2 reset, but is currently
using direct CM register accesses for this purpose. Implement a new API so
the PM code can use this instead.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cm3xxx.c |6 ++
arch/arm/mach-omap2/cm3xxx.h |1 +
arch/arm/mach-omap2/pm34xx.c |3 +--
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cm3xxx.c b/arch/arm/mach-omap2/cm3xxx.c
index 55bf939..b0509b9 100644
--- a/arch/arm/mach-omap2/cm3xxx.c
+++ b/arch/arm/mach-omap2/cm3xxx.c
@@ -696,6 +696,12 @@ void omap3_cm_force_iva_clk(bool enable)
omap2_cm_write_mod_reg(val, OMAP3430_IVA2_MOD, CM_FCLKEN);
}
+bool omap3_cm_is_iva_active(void)
+{
+ return omap2_cm_read_mod_reg(OMAP3430_IVA2_MOD, OMAP3430_CM_CLKSTST)
+ OMAP3430_CLKACTIVITY_IVA2_MASK;
+}
+
/*
*
*/
diff --git a/arch/arm/mach-omap2/cm3xxx.h b/arch/arm/mach-omap2/cm3xxx.h
index 61fdfc7..a944b5f 100644
--- a/arch/arm/mach-omap2/cm3xxx.h
+++ b/arch/arm/mach-omap2/cm3xxx.h
@@ -87,6 +87,7 @@ extern void omap3_cm_save_scratchpad_contents(u32 *ptr);
extern u32 omap3_cm_write_module_clken(s16 module, u8 regs, bool fck, u32 val);
extern u32 omap3_cm_read_module_clken(s16 module, u8 regs, bool fck);
extern void omap3_cm_force_iva_clk(bool enable);
+extern bool omap3_cm_is_iva_active(void);
extern int __init omap3xxx_cm_init(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ede058a..a73a012 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -415,8 +415,7 @@ static void __init omap3_iva_idle(void)
omap3_cm_force_iva_clk(false);
/* if no clock activity, nothing else to do */
- if (!(omap2_cm_read_mod_reg(OMAP3430_IVA2_MOD, OMAP3430_CM_CLKSTST)
- OMAP3430_CLKACTIVITY_IVA2_MASK))
+ if (!omap3_cm_is_iva_active())
return;
/* Reset IVA2 */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/11] ARM: OMAP3: control: add API for setting IVA bootmode
OMAP3 PM core requires IVA2 bootmode to be set to idle during init. Currently,
a direct register write is used for this. Add a new ctrl API for this purpose
instead.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/control.c | 11 +++
arch/arm/mach-omap2/control.h |1 +
arch/arm/mach-omap2/pm34xx.c |3 +--
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index a597114..44bb4d5 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -569,4 +569,15 @@ int omap3_ctrl_save_padconf(void)
return 0;
}
+/**
+ * omap3_ctrl_set_iva_bootmode_idle - sets the IVA2 bootmode to idle
+ *
+ * Sets the bootmode for IVA2 to idle. This is needed by the PM code to
+ * force disable IVA2 so that it does not prevent any low-power states.
+ */
+void omap3_ctrl_set_iva_bootmode_idle(void)
+{
+ omap_ctrl_writel(OMAP3_IVA2_BOOTMOD_IDLE,
+OMAP343X_CONTROL_IVA2_BOOTMOD);
+}
#endif /* CONFIG_ARCH_OMAP3 CONFIG_PM */
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index f7d7c2e..da05480 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -427,6 +427,7 @@ extern void omap_ctrl_write_dsp_boot_addr(u32 bootaddr);
extern void omap_ctrl_write_dsp_boot_mode(u8 bootmode);
extern void omap3630_ctrl_disable_rta(void);
extern int omap3_ctrl_save_padconf(void);
+extern void omap3_ctrl_set_iva_bootmode_idle(void);
extern void omap2_set_globals_control(void __iomem *ctrl,
void __iomem *ctrl_pad);
#else
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a73a012..a0c7e83 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -428,8 +428,7 @@ static void __init omap3_iva_idle(void)
omap3_cm_force_iva_clk(true);
/* Set IVA2 boot mode to 'idle' */
- omap_ctrl_writel(OMAP3_IVA2_BOOTMOD_IDLE,
-OMAP343X_CONTROL_IVA2_BOOTMOD);
+ omap3_ctrl_set_iva_bootmode_idle();
/* Un-reset IVA2 */
omap2_prm_write_mod_reg(0, OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/11] ARM: OMAP2: CM/PM: remove direct register accesses outside CM code
Users of the CM funtionality should not access the CM registers directly
by themselves. Thus, added new CM driver APIs for the OMAP2 specific
functionalities which support the existing direct register accesses, and
changed the platform code to use these. This is done in preparation
for moving the CM code into its own individual driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clkt2xxx_apll.c |4 +-
arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 11 ++---
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 24 +++--
arch/arm/mach-omap2/cm2xxx.c | 67 ++
arch/arm/mach-omap2/cm2xxx.h |8 +++
arch/arm/mach-omap2/pm24xx.c | 24 +
6 files changed, 89 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt2xxx_apll.c
b/arch/arm/mach-omap2/clkt2xxx_apll.c
index 25b1fee..c78e893 100644
--- a/arch/arm/mach-omap2/clkt2xxx_apll.c
+++ b/arch/arm/mach-omap2/clkt2xxx_apll.c
@@ -52,7 +52,7 @@ static bool omap2xxx_clk_apll_locked(struct clk_hw *hw)
apll_mask = EN_APLL_LOCKED clk-enable_bit;
- r = omap2_cm_read_mod_reg(PLL_MOD, CM_CLKEN);
+ r = omap2xxx_cm_get_pll_status();
return ((r apll_mask) == apll_mask) ? true : false;
}
@@ -126,7 +126,7 @@ u32 omap2xxx_get_apll_clkin(void)
{
u32 aplls, srate = 0;
- aplls = omap2_cm_read_mod_reg(PLL_MOD, CM_CLKSEL1);
+ aplls = omap2xxx_cm_get_pll_config();
aplls = OMAP24XX_APLLS_CLKIN_MASK;
aplls = OMAP24XX_APLLS_CLKIN_SHIFT;
diff --git a/arch/arm/mach-omap2/clkt2xxx_dpllcore.c
b/arch/arm/mach-omap2/clkt2xxx_dpllcore.c
index d862010..3ff3254 100644
--- a/arch/arm/mach-omap2/clkt2xxx_dpllcore.c
+++ b/arch/arm/mach-omap2/clkt2xxx_dpllcore.c
@@ -60,8 +60,7 @@ unsigned long omap2xxx_clk_get_core_rate(void)
core_clk = omap2_get_dpll_rate(dpll_core_ck);
- v = omap2_cm_read_mod_reg(PLL_MOD, CM_CLKSEL2);
- v = OMAP24XX_CORE_CLK_SRC_MASK;
+ v = omap2xxx_cm_get_core_clk_src();
if (v == CORE_CLK_SRC_32K)
core_clk = 32768;
@@ -79,8 +78,7 @@ static long omap2_dpllcore_round_rate(unsigned long
target_rate)
{
u32 high, low, core_clk_src;
- core_clk_src = omap2_cm_read_mod_reg(PLL_MOD, CM_CLKSEL2);
- core_clk_src = OMAP24XX_CORE_CLK_SRC_MASK;
+ core_clk_src = omap2xxx_cm_get_core_clk_src();
if (core_clk_src == CORE_CLK_SRC_DPLL) {/* DPLL clockout */
high = curr_prcm_set-dpll_speed * 2;
@@ -120,8 +118,7 @@ int omap2_reprogram_dpllcore(struct clk_hw *hw, unsigned
long rate,
const struct dpll_data *dd;
cur_rate = omap2xxx_clk_get_core_rate();
- mult = omap2_cm_read_mod_reg(PLL_MOD, CM_CLKSEL2);
- mult = OMAP24XX_CORE_CLK_SRC_MASK;
+ mult = omap2xxx_cm_get_core_clk_src();
if ((rate == (cur_rate / 2)) (mult == 2)) {
omap2xxx_sdrc_reprogram(CORE_CLK_SRC_DPLL, 1);
@@ -145,7 +142,7 @@ int omap2_reprogram_dpllcore(struct clk_hw *hw, unsigned
long rate,
tmpset.cm_clksel1_pll = ~(dd-mult_mask |
dd-div1_mask);
div = ((curr_prcm_set-xtal_speed / 100) - 1);
- tmpset.cm_clksel2_pll = omap2_cm_read_mod_reg(PLL_MOD,
CM_CLKSEL2);
+ tmpset.cm_clksel2_pll = omap2xxx_cm_get_core_pll_config();
tmpset.cm_clksel2_pll = ~OMAP24XX_CORE_CLK_SRC_MASK;
if (rate low) {
tmpset.cm_clksel2_pll |= CORE_CLK_SRC_DPLL_X2;
diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
index ae2b35e..b935ed2 100644
--- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
+++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
@@ -98,7 +98,7 @@ long omap2_round_to_table_rate(struct clk_hw *hw, unsigned
long rate,
int omap2_select_table_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
- u32 cur_rate, done_rate, bypass = 0, tmp;
+ u32 cur_rate, done_rate, bypass = 0;
const struct prcm_config *prcm;
unsigned long found_speed = 0;
unsigned long flags;
@@ -141,23 +141,11 @@ int omap2_select_table_rate(struct clk_hw *hw, unsigned
long rate,
else
done_rate = CORE_CLK_SRC_DPLL;
- /* MPU divider */
- omap2_cm_write_mod_reg(prcm-cm_clksel_mpu, MPU_MOD, CM_CLKSEL);
-
- /* dsp + iva1 div(2420), iva2.1(2430) */
- omap2_cm_write_mod_reg(prcm-cm_clksel_dsp,
-OMAP24XX_DSP_MOD, CM_CLKSEL);
-
- omap2_cm_write_mod_reg(prcm-cm_clksel_gfx, GFX_MOD, CM_CLKSEL);
-
- /* Major subsystem dividers */
- tmp = omap2_cm_read_mod_reg(CORE_MOD, CM_CLKSEL1)
OMAP24XX_CLKSEL_DSS2_MASK;
-
[PATCH 06/11] ARM: OMAP3: CM/PM: add API for forcing IVA2 clk enable/disable
OMAP3 PM code directly writes to CM register space to enable/disable IVA2
clock during boot during the IVA2 reset. Direct access shall be avoided,
thus implement an API call for this, and change the PM core to use this.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cm3xxx.c | 10 ++
arch/arm/mach-omap2/cm3xxx.h |1 +
arch/arm/mach-omap2/pm34xx.c |7 +++
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/cm3xxx.c b/arch/arm/mach-omap2/cm3xxx.c
index f13742b..55bf939 100644
--- a/arch/arm/mach-omap2/cm3xxx.c
+++ b/arch/arm/mach-omap2/cm3xxx.c
@@ -686,6 +686,16 @@ u32 omap3_cm_write_module_clken(s16 module, u8 regs, bool
fck, u32 val)
return omap3_cm_access_module_clken(module, regs, fck, val, true);
}
+void omap3_cm_force_iva_clk(bool enable)
+{
+ u32 val = 0;
+
+ if (enable)
+ val = OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK;
+
+ omap2_cm_write_mod_reg(val, OMAP3430_IVA2_MOD, CM_FCLKEN);
+}
+
/*
*
*/
diff --git a/arch/arm/mach-omap2/cm3xxx.h b/arch/arm/mach-omap2/cm3xxx.h
index 2481781..61fdfc7 100644
--- a/arch/arm/mach-omap2/cm3xxx.h
+++ b/arch/arm/mach-omap2/cm3xxx.h
@@ -86,6 +86,7 @@ extern void omap3_cm_restore_context(void);
extern void omap3_cm_save_scratchpad_contents(u32 *ptr);
extern u32 omap3_cm_write_module_clken(s16 module, u8 regs, bool fck, u32 val);
extern u32 omap3_cm_read_module_clken(s16 module, u8 regs, bool fck);
+extern void omap3_cm_force_iva_clk(bool enable);
extern int __init omap3xxx_cm_init(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index f3ba439..ede058a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -412,7 +412,7 @@ restore:
static void __init omap3_iva_idle(void)
{
/* ensure IVA2 clock is disabled */
- omap2_cm_write_mod_reg(0, OMAP3430_IVA2_MOD, CM_FCLKEN);
+ omap3_cm_force_iva_clk(false);
/* if no clock activity, nothing else to do */
if (!(omap2_cm_read_mod_reg(OMAP3430_IVA2_MOD, OMAP3430_CM_CLKSTST)
@@ -426,8 +426,7 @@ static void __init omap3_iva_idle(void)
OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
/* Enable IVA2 clock */
- omap2_cm_write_mod_reg(OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK,
-OMAP3430_IVA2_MOD, CM_FCLKEN);
+ omap3_cm_force_iva_clk(true);
/* Set IVA2 boot mode to 'idle' */
omap_ctrl_writel(OMAP3_IVA2_BOOTMOD_IDLE,
@@ -437,7 +436,7 @@ static void __init omap3_iva_idle(void)
omap2_prm_write_mod_reg(0, OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
/* Disable IVA2 clock */
- omap2_cm_write_mod_reg(0, OMAP3430_IVA2_MOD, CM_FCLKEN);
+ omap3_cm_force_iva_clk(false);
/* Reset IVA2 */
omap2_prm_write_mod_reg(OMAP3430_RST1_IVA2_MASK |
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/11] ARM: OMAP2+: CM cleanup series
Hi, A small cleanup set for CM. This basically gets rid of the omap2_cm_* register accesses from the random code locations, and gathers these under cm2xxx.c and cm3xxx.c. This is done in preparation for creating a separate CM driver. The set also contains a couple of PRM cleanups which I decided to take care of at the same time due to overlapping code (PRCM interrupt handler + DSP reset.) TODO: cleanup dsp bridge code (arch/arm/mach-omap2/dsp.c.) Tested on OMAP3 beagle + 3.12-rc3. If someone could verify the omap2 changes, that would be nice. -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
[PATCH 03/11] ARM: OMAP3: McBSP: do not access CM register directly
McBSP driver require special hacks to enable/disable the autoidle feature
for its interface clock for the proper function of the sidetone hardware.
Currently the driver just writes CM registers directly, which should be
avoided. Thus, changed the driver to use the new deny/allow_autoidle
clock API calls.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/mcbsp.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 5d87680..b4ac3af 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -25,6 +25,7 @@
#include soc.h
#include omap_device.h
+#include clock.h
/*
* FIXME: Find a mechanism to enable/disable runtime the McBSP ICLK autoidle.
@@ -33,22 +34,18 @@
#include cm3xxx.h
#include cm-regbits-34xx.h
+static struct clk *mcbsp_iclks[5];
+
static int omap3_enable_st_clock(unsigned int id, bool enable)
{
- unsigned int w;
-
/*
* Sidetone uses McBSP ICLK - which must not idle when sidetones
* are enabled or sidetones start sounding ugly.
*/
- w = omap2_cm_read_mod_reg(OMAP3430_PER_MOD, CM_AUTOIDLE);
if (enable)
- w = ~(1 (id - 2));
+ return omap2_clk_deny_idle(mcbsp_iclks[id]);
else
- w |= 1 (id - 2);
- omap2_cm_write_mod_reg(w, OMAP3430_PER_MOD, CM_AUTOIDLE);
-
- return 0;
+ return omap2_clk_allow_idle(mcbsp_iclks[id]);
}
static int __init omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
@@ -58,6 +55,7 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh, void
*unused)
struct omap_hwmod *oh_device[2];
struct omap_mcbsp_platform_data *pdata = NULL;
struct platform_device *pdev;
+ char clk_name[11];
sscanf(oh-name, mcbsp%d, id);
@@ -99,6 +97,8 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh, void
*unused)
oh_device[1] = omap_hwmod_lookup((
(struct omap_mcbsp_dev_attr *)(oh-dev_attr))-sidetone);
pdata-enable_st_clock = omap3_enable_st_clock;
+ sprintf(clk_name, mcbsp%d_ick, id);
+ mcbsp_iclks[id] = clk_get(NULL, clk_name);
count++;
}
pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] ARM: OMAP3: clock: add API to enable/disable autoidle for a single clock
Some drivers require direct access to the autoidle functionality of the
interface clocks. Added clock APIs for these, so that the drivers do not
need to access CM registers directly.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock.c | 38 ++
arch/arm/mach-omap2/clock.h |2 ++
2 files changed, 40 insertions(+)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 0c38ca9..c7c5d31 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -543,6 +543,44 @@ int omap2_clk_disable_autoidle_all(void)
}
/**
+ * omap2_clk_deny_idle - disable autoidle on an OMAP clock
+ * @clk: struct clk * to disable autoidle for
+ *
+ * Disable autoidle on an OMAP clock.
+ */
+int omap2_clk_deny_idle(struct clk *clk)
+{
+ struct clk_hw_omap *c;
+
+ if (__clk_get_flags(clk) CLK_IS_BASIC)
+ return -EINVAL;
+
+ c = to_clk_hw_omap(__clk_get_hw(clk));
+ if (c-ops c-ops-deny_idle)
+ c-ops-deny_idle(c);
+ return 0;
+}
+
+/**
+ * omap2_clk_allow_idle - enable autoidle on an OMAP clock
+ * @clk: struct clk * to enable autoidle for
+ *
+ * Enable autoidle on an OMAP clock.
+ */
+int omap2_clk_allow_idle(struct clk *clk)
+{
+ struct clk_hw_omap *c;
+
+ if (__clk_get_flags(clk) CLK_IS_BASIC)
+ return -EINVAL;
+
+ c = to_clk_hw_omap(__clk_get_hw(clk));
+ if (c-ops c-ops-allow_idle)
+ c-ops-allow_idle(c);
+ return 0;
+}
+
+/**
* omap2_clk_enable_init_clocks - prepare enable a list of clocks
* @clk_names: ptr to an array of strings of clock names to enable
* @num_clocks: number of clock names in @clk_names
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 7aa32cd..82916cc 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -411,6 +411,8 @@ void omap2_clk_dflt_find_idlest(struct clk_hw_omap *clk,
void omap2_init_clk_hw_omap_clocks(struct clk *clk);
int omap2_clk_enable_autoidle_all(void);
int omap2_clk_disable_autoidle_all(void);
+int omap2_clk_allow_idle(struct clk *clk);
+int omap2_clk_deny_idle(struct clk *clk);
void omap2_clk_enable_init_clocks(const char **clk_names, u8 num_clocks);
int omap2_clk_switch_mpurate_at_boot(const char *mpurate_ck_name);
void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/11] ARM: OMAP3: CM/control: move CM scratchpad save to CM driver
OMAP3 PM code for off-mode currently saves the scratchpad contents for CM
registers within OMAP control module driver. However, as we are separating
CM code into its own driver, this must be moved also. This patch adds a
new API for saving the CM scratchpad contents and uses this from the high
level scratchpad save function.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cm3xxx.c | 22 +
arch/arm/mach-omap2/cm3xxx.h |1 +
arch/arm/mach-omap2/control.c | 43 -
3 files changed, 27 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/cm3xxx.c b/arch/arm/mach-omap2/cm3xxx.c
index 9061c30..f6f0288 100644
--- a/arch/arm/mach-omap2/cm3xxx.c
+++ b/arch/arm/mach-omap2/cm3xxx.c
@@ -636,6 +636,28 @@ void omap3_cm_restore_context(void)
OMAP3_CM_CLKOUT_CTRL_OFFSET);
}
+void omap3_cm_save_scratchpad_contents(u32 *ptr)
+{
+ *ptr++ = omap2_cm_read_mod_reg(CORE_MOD, CM_CLKSEL);
+ *ptr++ = omap2_cm_read_mod_reg(WKUP_MOD, CM_CLKSEL);
+ *ptr++ = omap2_cm_read_mod_reg(PLL_MOD, CM_CLKEN);
+
+ /*
+* As per erratum i671, ROM code does not respect the PER DPLL
+* programming scheme if CM_AUTOIDLE_PLL..AUTO_PERIPH_DPLL == 1.
+* Then, in anycase, clear these bits to avoid extra latencies.
+*/
+ *ptr++ = omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE)
+ ~OMAP3430_AUTO_PERIPH_DPLL_MASK;
+ *ptr++ = omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
+ *ptr++ = omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL2_PLL);
+ *ptr++ = omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL3);
+ *ptr++ = omap2_cm_read_mod_reg(MPU_MOD, OMAP3430_CM_CLKEN_PLL);
+ *ptr++ = omap2_cm_read_mod_reg(MPU_MOD, OMAP3430_CM_AUTOIDLE_PLL);
+ *ptr++ = omap2_cm_read_mod_reg(MPU_MOD, OMAP3430_CM_CLKSEL1_PLL);
+ *ptr++ = omap2_cm_read_mod_reg(MPU_MOD, OMAP3430_CM_CLKSEL2_PLL);
+}
+
/*
*
*/
diff --git a/arch/arm/mach-omap2/cm3xxx.h b/arch/arm/mach-omap2/cm3xxx.h
index e8e146f..8224c91 100644
--- a/arch/arm/mach-omap2/cm3xxx.h
+++ b/arch/arm/mach-omap2/cm3xxx.h
@@ -83,6 +83,7 @@ extern int omap3xxx_cm_split_idlest_reg(void __iomem
*idlest_reg,
extern void omap3_cm_save_context(void);
extern void omap3_cm_restore_context(void);
+extern void omap3_cm_save_scratchpad_contents(u32 *ptr);
extern int __init omap3xxx_cm_init(void);
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 31e0dfe..a597114 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -46,17 +46,7 @@ struct omap3_scratchpad {
struct omap3_scratchpad_prcm_block {
u32 prm_clksrc_ctrl;
u32 prm_clksel;
- u32 cm_clksel_core;
- u32 cm_clksel_wkup;
- u32 cm_clken_pll;
- u32 cm_autoidle_pll;
- u32 cm_clksel1_pll;
- u32 cm_clksel2_pll;
- u32 cm_clksel3_pll;
- u32 cm_clken_pll_mpu;
- u32 cm_autoidle_pll_mpu;
- u32 cm_clksel1_pll_mpu;
- u32 cm_clksel2_pll_mpu;
+ u32 cm_contents[11];
u32 prcm_block_size;
};
@@ -347,34 +337,9 @@ void omap3_save_scratchpad_contents(void)
prcm_block_contents.prm_clksel =
omap2_prm_read_mod_reg(OMAP3430_CCR_MOD,
OMAP3_PRM_CLKSEL_OFFSET);
- prcm_block_contents.cm_clksel_core =
- omap2_cm_read_mod_reg(CORE_MOD, CM_CLKSEL);
- prcm_block_contents.cm_clksel_wkup =
- omap2_cm_read_mod_reg(WKUP_MOD, CM_CLKSEL);
- prcm_block_contents.cm_clken_pll =
- omap2_cm_read_mod_reg(PLL_MOD, CM_CLKEN);
- /*
-* As per erratum i671, ROM code does not respect the PER DPLL
-* programming scheme if CM_AUTOIDLE_PLL..AUTO_PERIPH_DPLL == 1.
-* Then, in anycase, clear these bits to avoid extra latencies.
-*/
- prcm_block_contents.cm_autoidle_pll =
- omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE)
- ~OMAP3430_AUTO_PERIPH_DPLL_MASK;
- prcm_block_contents.cm_clksel1_pll =
- omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
- prcm_block_contents.cm_clksel2_pll =
- omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL2_PLL);
- prcm_block_contents.cm_clksel3_pll =
- omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL3);
- prcm_block_contents.cm_clken_pll_mpu =
- omap2_cm_read_mod_reg(MPU_MOD, OMAP3430_CM_CLKEN_PLL);
- prcm_block_contents.cm_autoidle_pll_mpu =
- omap2_cm_read_mod_reg(MPU_MOD,
OMAP3430_CM_AUTOIDLE_PLL);
- prcm_block_contents.cm_clksel1_pll_mpu =
- omap2_cm_read_mod_reg(MPU_MOD, OMAP3430_CM_CLKSEL1_PLL);
- prcm_block_contents.cm_clksel2_pll_mpu =
-
[PATCH 05/11] ARM: OMAP3: CM/PM: add API for accessing module clock enable registers
PRCM chain handler needs these to properly acknowledge wakeup events.
Currently this functionality is implemented as direct register accesses,
but as the CM code should eventually move to its own driver, separate
API calls are now added for this purpose. PM core code is also changed
to use these APIs.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cm3xxx.c | 28
arch/arm/mach-omap2/cm3xxx.h |2 ++
arch/arm/mach-omap2/pm34xx.c | 16
3 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/cm3xxx.c b/arch/arm/mach-omap2/cm3xxx.c
index f6f0288..f13742b 100644
--- a/arch/arm/mach-omap2/cm3xxx.c
+++ b/arch/arm/mach-omap2/cm3xxx.c
@@ -658,6 +658,34 @@ void omap3_cm_save_scratchpad_contents(u32 *ptr)
*ptr++ = omap2_cm_read_mod_reg(MPU_MOD, OMAP3430_CM_CLKSEL2_PLL);
}
+static u32 omap3_cm_access_module_clken(s16 module, u8 regs, bool fck, u32 val,
+ bool write)
+{
+ u16 offset;
+
+ if (fck)
+ offset = (regs == 3) ? OMAP3430ES2_CM_FCLKEN3 : CM_FCLKEN1;
+ else
+ offset = (regs == 3) ? CM_ICLKEN3 : CM_ICLKEN1;
+
+ if (write)
+ omap2_cm_write_mod_reg(val, module, offset);
+ else
+ val = omap2_cm_read_mod_reg(module, offset);
+
+ return val;
+}
+
+u32 omap3_cm_read_module_clken(s16 module, u8 regs, bool fck)
+{
+ return omap3_cm_access_module_clken(module, regs, fck, 0, false);
+}
+
+u32 omap3_cm_write_module_clken(s16 module, u8 regs, bool fck, u32 val)
+{
+ return omap3_cm_access_module_clken(module, regs, fck, val, true);
+}
+
/*
*
*/
diff --git a/arch/arm/mach-omap2/cm3xxx.h b/arch/arm/mach-omap2/cm3xxx.h
index 8224c91..2481781 100644
--- a/arch/arm/mach-omap2/cm3xxx.h
+++ b/arch/arm/mach-omap2/cm3xxx.h
@@ -84,6 +84,8 @@ extern int omap3xxx_cm_split_idlest_reg(void __iomem
*idlest_reg,
extern void omap3_cm_save_context(void);
extern void omap3_cm_restore_context(void);
extern void omap3_cm_save_scratchpad_contents(u32 *ptr);
+extern u32 omap3_cm_write_module_clken(s16 module, u8 regs, bool fck, u32 val);
+extern u32 omap3_cm_read_module_clken(s16 module, u8 regs, bool fck);
extern int __init omap3xxx_cm_init(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 5a2d803..f3ba439 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -146,8 +146,6 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs, u32
ignore_bits)
{
u32 wkst, fclk, iclk, clken;
u16 wkst_off = (regs == 3) ? OMAP3430ES2_PM_WKST3 : PM_WKST1;
- u16 fclk_off = (regs == 3) ? OMAP3430ES2_CM_FCLKEN3 : CM_FCLKEN1;
- u16 iclk_off = (regs == 3) ? CM_ICLKEN3 : CM_ICLKEN1;
u16 grpsel_off = (regs == 3) ?
OMAP3430ES2_PM_MPUGRPSEL3 : OMAP3430_PM_MPUGRPSEL;
int c = 0;
@@ -156,25 +154,27 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs, u32
ignore_bits)
wkst = omap2_prm_read_mod_reg(module, grpsel_off);
wkst = ~ignore_bits;
if (wkst) {
- iclk = omap2_cm_read_mod_reg(module, iclk_off);
- fclk = omap2_cm_read_mod_reg(module, fclk_off);
+ iclk = omap3_cm_read_module_clken(module, regs, false);
+ fclk = omap3_cm_read_module_clken(module, regs, true);
while (wkst) {
clken = wkst;
- omap2_cm_set_mod_reg_bits(clken, module, iclk_off);
+ omap3_cm_write_module_clken(module, regs, false,
+ iclk | clken);
/*
* For USBHOST, we don't know whether HOST1 or
* HOST2 woke us up, so enable both f-clocks
*/
if (module == OMAP3430ES2_USBHOST_MOD)
clken |= 1 OMAP3430ES2_EN_USBHOST2_SHIFT;
- omap2_cm_set_mod_reg_bits(clken, module, fclk_off);
+ omap3_cm_write_module_clken(module, regs, true,
+ fclk | clken);
omap2_prm_write_mod_reg(wkst, module, wkst_off);
wkst = omap2_prm_read_mod_reg(module, wkst_off);
wkst = ~ignore_bits;
c++;
}
- omap2_cm_write_mod_reg(iclk, module, iclk_off);
- omap2_cm_write_mod_reg(fclk, module, fclk_off);
+ omap3_cm_write_module_clken(module, regs, false, iclk);
+ omap3_cm_write_module_clken(module, regs, true, fclk);
}
return c;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/11] ARM: OMAP3: PRM: move PRCM interrupt handler helper to PRM driver
PM core code should not directly access PRM registers. Thus move the
PRCM interrupt handler helper out of the core PM code to PRM driver,
and use the new API from the core.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 65 ++---
arch/arm/mach-omap2/prm3xxx.c | 79 +
arch/arm/mach-omap2/prm3xxx.h |2 ++
3 files changed, 83 insertions(+), 63 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 4320541..6a5302a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -132,60 +132,11 @@ static void omap3_save_secure_ram_context(void)
}
}
-/*
- * PRCM Interrupt Handler Helper Function
- *
- * The purpose of this function is to clear any wake-up events latched
- * in the PRCM PM_WKST_x registers. It is possible that a wake-up event
- * may occur whilst attempting to clear a PM_WKST_x register and thus
- * set another bit in this register. A while loop is used to ensure
- * that any peripheral wake-up events occurring while attempting to
- * clear the PM_WKST_x are detected and cleared.
- */
-static int prcm_clear_mod_irqs(s16 module, u8 regs, u32 ignore_bits)
-{
- u32 wkst, fclk, iclk, clken;
- u16 wkst_off = (regs == 3) ? OMAP3430ES2_PM_WKST3 : PM_WKST1;
- u16 grpsel_off = (regs == 3) ?
- OMAP3430ES2_PM_MPUGRPSEL3 : OMAP3430_PM_MPUGRPSEL;
- int c = 0;
-
- wkst = omap2_prm_read_mod_reg(module, wkst_off);
- wkst = omap2_prm_read_mod_reg(module, grpsel_off);
- wkst = ~ignore_bits;
- if (wkst) {
- iclk = omap3_cm_read_module_clken(module, regs, false);
- fclk = omap3_cm_read_module_clken(module, regs, true);
- while (wkst) {
- clken = wkst;
- omap3_cm_write_module_clken(module, regs, false,
- iclk | clken);
- /*
-* For USBHOST, we don't know whether HOST1 or
-* HOST2 woke us up, so enable both f-clocks
-*/
- if (module == OMAP3430ES2_USBHOST_MOD)
- clken |= 1 OMAP3430ES2_EN_USBHOST2_SHIFT;
- omap3_cm_write_module_clken(module, regs, true,
- fclk | clken);
- omap2_prm_write_mod_reg(wkst, module, wkst_off);
- wkst = omap2_prm_read_mod_reg(module, wkst_off);
- wkst = ~ignore_bits;
- c++;
- }
- omap3_cm_write_module_clken(module, regs, false, iclk);
- omap3_cm_write_module_clken(module, regs, true, fclk);
- }
-
- return c;
-}
-
static irqreturn_t _prcm_int_handle_io(int irq, void *unused)
{
int c;
- c = prcm_clear_mod_irqs(WKUP_MOD, 1,
- ~(OMAP3430_ST_IO_MASK | OMAP3430_ST_IO_CHAIN_MASK));
+ c = omap3_prcm_clear_io_irq();
return c ? IRQ_HANDLED : IRQ_NONE;
}
@@ -194,19 +145,7 @@ static irqreturn_t _prcm_int_handle_wakeup(int irq, void
*unused)
{
int c;
- /*
-* Clear all except ST_IO and ST_IO_CHAIN for wkup module,
-* these are handled in a separate handler to avoid acking
-* IO events before parsing in mux code
-*/
- c = prcm_clear_mod_irqs(WKUP_MOD, 1,
- OMAP3430_ST_IO_MASK | OMAP3430_ST_IO_CHAIN_MASK);
- c += prcm_clear_mod_irqs(CORE_MOD, 1, 0);
- c += prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1, 0);
- if (omap_rev() OMAP3430_REV_ES1_0) {
- c += prcm_clear_mod_irqs(CORE_MOD, 3, 0);
- c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1, 0);
- }
+ c = omap3_prcm_clear_wkup_irq();
return c ? IRQ_HANDLED : IRQ_NONE;
}
diff --git a/arch/arm/mach-omap2/prm3xxx.c b/arch/arm/mach-omap2/prm3xxx.c
index 3813e9a..50177e9 100644
--- a/arch/arm/mach-omap2/prm3xxx.c
+++ b/arch/arm/mach-omap2/prm3xxx.c
@@ -27,6 +27,7 @@
#include cm2xxx_3xxx.h
#include prm-regbits-34xx.h
#include cm3xxx.h
+#include cm-regbits-34xx.h
#include control.h
static const struct omap_prcm_irq omap3_prcm_irqs[] = {
@@ -399,6 +400,84 @@ struct pwrdm_ops omap3_pwrdm_operations = {
};
/**
+ * omap3_prcm_clear_mod_irqs: PRCM interrupt handler helper function
+ * @module: module offset
+ * @regs: register index
+ * @ignore_bits: bit-mask to ignore while checking wakeup status
+ *
+ * The purpose of this function is to clear any wake-up events latched
+ * in the PRCM PM_WKST_x registers. It is possible that a wake-up event
+ * may occur whilst attempting to clear a PM_WKST_x register and thus
+ * set another bit in this register. A while loop is used to ensure
+ * that any peripheral wake-up events occurring while attempting to
+ * clear
[PATCH 11/11] ARM: OMAP2+: CM: move direct register write macros to internal header
The direct register access macros should not be exposed to CM clients.
Thus, move the register macros to their own file and only include these
to the cm_*.c files.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cm2xxx.c |1 +
arch/arm/mach-omap2/cm2xxx_3xxx.h | 48 --
arch/arm/mach-omap2/cm3xxx.c |1 +
arch/arm/mach-omap2/cm_internal.h | 67 +
4 files changed, 69 insertions(+), 48 deletions(-)
create mode 100644 arch/arm/mach-omap2/cm_internal.h
diff --git a/arch/arm/mach-omap2/cm2xxx.c b/arch/arm/mach-omap2/cm2xxx.c
index ce25abb..c7facf1 100644
--- a/arch/arm/mach-omap2/cm2xxx.c
+++ b/arch/arm/mach-omap2/cm2xxx.c
@@ -26,6 +26,7 @@
#include cm2xxx.h
#include cm-regbits-24xx.h
#include clockdomain.h
+#include cm_internal.h
/* CM_AUTOIDLE_PLL.AUTO_* bit values for DPLLs */
#define DPLL_AUTOIDLE_DISABLE 0x0
diff --git a/arch/arm/mach-omap2/cm2xxx_3xxx.h
b/arch/arm/mach-omap2/cm2xxx_3xxx.h
index bfbd16f..b40b5bd 100644
--- a/arch/arm/mach-omap2/cm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/cm2xxx_3xxx.h
@@ -48,54 +48,6 @@
#ifndef __ASSEMBLER__
-#include linux/io.h
-
-static inline u32 omap2_cm_read_mod_reg(s16 module, u16 idx)
-{
- return __raw_readl(cm_base + module + idx);
-}
-
-static inline void omap2_cm_write_mod_reg(u32 val, s16 module, u16 idx)
-{
- __raw_writel(val, cm_base + module + idx);
-}
-
-/* Read-modify-write a register in a CM module. Caller must lock */
-static inline u32 omap2_cm_rmw_mod_reg_bits(u32 mask, u32 bits, s16 module,
- s16 idx)
-{
- u32 v;
-
- v = omap2_cm_read_mod_reg(module, idx);
- v = ~mask;
- v |= bits;
- omap2_cm_write_mod_reg(v, module, idx);
-
- return v;
-}
-
-/* Read a CM register, AND it, and shift the result down to bit 0 */
-static inline u32 omap2_cm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask)
-{
- u32 v;
-
- v = omap2_cm_read_mod_reg(domain, idx);
- v = mask;
- v = __ffs(mask);
-
- return v;
-}
-
-static inline u32 omap2_cm_set_mod_reg_bits(u32 bits, s16 module, s16 idx)
-{
- return omap2_cm_rmw_mod_reg_bits(bits, bits, module, idx);
-}
-
-static inline u32 omap2_cm_clear_mod_reg_bits(u32 bits, s16 module, s16 idx)
-{
- return omap2_cm_rmw_mod_reg_bits(bits, 0x0, module, idx);
-}
-
extern int omap2xxx_cm_apll54_enable(void);
extern void omap2xxx_cm_apll54_disable(void);
extern int omap2xxx_cm_apll96_enable(void);
diff --git a/arch/arm/mach-omap2/cm3xxx.c b/arch/arm/mach-omap2/cm3xxx.c
index b0509b9..ccd29ba 100644
--- a/arch/arm/mach-omap2/cm3xxx.c
+++ b/arch/arm/mach-omap2/cm3xxx.c
@@ -26,6 +26,7 @@
#include cm3xxx.h
#include cm-regbits-34xx.h
#include clockdomain.h
+#include cm_internal.h
static const u8 omap3xxx_cm_idlest_offs[] = {
CM_IDLEST1, CM_IDLEST2, OMAP2430_CM_IDLEST3
diff --git a/arch/arm/mach-omap2/cm_internal.h
b/arch/arm/mach-omap2/cm_internal.h
new file mode 100644
index 000..929157d
--- /dev/null
+++ b/arch/arm/mach-omap2/cm_internal.h
@@ -0,0 +1,67 @@
+/*
+ * OMAP2+ Clock Management (CM) internal header
+ *
+ * Copyright (C) 2007-2013 Texas Instruments, Inc.
+ * Copyright (C) 2007-2010 Nokia Corporation
+ * Paul Walmsley
+ *
+ * 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.
+ *
+ * The CM hardware modules on the OMAP2/3 are quite similar to each
+ * other. The CM modules/instances on OMAP4 are quite different, so
+ * they are handled in a separate file.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_CM_INTERNAL_H
+#define __ARCH_ARM_MACH_OMAP2_CM_INTERNAL_H
+
+#include linux/io.h
+
+static inline u32 omap2_cm_read_mod_reg(s16 module, u16 idx)
+{
+ return __raw_readl(cm_base + module + idx);
+}
+
+static inline void omap2_cm_write_mod_reg(u32 val, s16 module, u16 idx)
+{
+ __raw_writel(val, cm_base + module + idx);
+}
+
+/* Read-modify-write a register in a CM module. Caller must lock */
+static inline u32 omap2_cm_rmw_mod_reg_bits(u32 mask, u32 bits, s16 module,
+ s16 idx)
+{
+ u32 v;
+
+ v = omap2_cm_read_mod_reg(module, idx);
+ v = ~mask;
+ v |= bits;
+ omap2_cm_write_mod_reg(v, module, idx);
+
+ return v;
+}
+
+/* Read a CM register, AND it, and shift the result down to bit 0 */
+static inline u32 omap2_cm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask)
+{
+ u32 v;
+
+ v = omap2_cm_read_mod_reg(domain, idx);
+ v = mask;
+ v = __ffs(mask);
+
+ return v;
+}
+
+static inline u32 omap2_cm_set_mod_reg_bits(u32 bits, s16 module, s16 idx)
+{
+ return omap2_cm_rmw_mod_reg_bits(bits, bits, module, idx);
+}
+
+static inline u32 omap2_cm_clear_mod_reg_bits(u32 bits, s16 module, s16 idx)
+{
+ return
[PATCH 09/11] ARM: OMAP3: PRM: move iva2 force idle functionality to PRM driver
This is correct location for this instead of the PM core, as it is accessing
PRM registers directly.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 48 +
arch/arm/mach-omap2/prm3xxx.c | 45 ++
arch/arm/mach-omap2/prm3xxx.h |2 ++
3 files changed, 48 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a0c7e83..4320541 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -398,51 +398,6 @@ restore:
#endif /* CONFIG_SUSPEND */
-
-/**
- * omap3_iva_idle(): ensure IVA is in idle so it can be put into
- * retention
- *
- * In cases where IVA2 is activated by bootcode, it may prevent
- * full-chip retention or off-mode because it is not idle. This
- * function forces the IVA2 into idle state so it can go
- * into retention/off and thus allow full-chip retention/off.
- *
- **/
-static void __init omap3_iva_idle(void)
-{
- /* ensure IVA2 clock is disabled */
- omap3_cm_force_iva_clk(false);
-
- /* if no clock activity, nothing else to do */
- if (!omap3_cm_is_iva_active())
- return;
-
- /* Reset IVA2 */
- omap2_prm_write_mod_reg(OMAP3430_RST1_IVA2_MASK |
- OMAP3430_RST2_IVA2_MASK |
- OMAP3430_RST3_IVA2_MASK,
- OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
-
- /* Enable IVA2 clock */
- omap3_cm_force_iva_clk(true);
-
- /* Set IVA2 boot mode to 'idle' */
- omap3_ctrl_set_iva_bootmode_idle();
-
- /* Un-reset IVA2 */
- omap2_prm_write_mod_reg(0, OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
-
- /* Disable IVA2 clock */
- omap3_cm_force_iva_clk(false);
-
- /* Reset IVA2 */
- omap2_prm_write_mod_reg(OMAP3430_RST1_IVA2_MASK |
- OMAP3430_RST2_IVA2_MASK |
- OMAP3430_RST3_IVA2_MASK,
- OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
-}
-
static void __init omap3_d2d_idle(void)
{
u16 mask, padconf;
@@ -546,8 +501,7 @@ static void __init prcm_setup_regs(void)
/*
* We need to idle iva2_pwrdm even on am3703 with no iva2.
*/
- omap3_iva_idle();
-
+ omap3_prm_force_idle_iva();
omap3_d2d_idle();
}
diff --git a/arch/arm/mach-omap2/prm3xxx.c b/arch/arm/mach-omap2/prm3xxx.c
index 7721990..3813e9a 100644
--- a/arch/arm/mach-omap2/prm3xxx.c
+++ b/arch/arm/mach-omap2/prm3xxx.c
@@ -26,6 +26,8 @@
#include prm2xxx_3xxx.h
#include cm2xxx_3xxx.h
#include prm-regbits-34xx.h
+#include cm3xxx.h
+#include control.h
static const struct omap_prcm_irq omap3_prcm_irqs[] = {
OMAP_PRCM_IRQ(wkup, 0, 0),
@@ -396,6 +398,49 @@ struct pwrdm_ops omap3_pwrdm_operations = {
.pwrdm_wait_transition = omap2_pwrdm_wait_transition,
};
+/**
+ * omap3_prcm_force_idle_iva: ensure IVA is in idle so it can be put into
+ * retention
+ *
+ * In cases where IVA2 is activated by bootcode, it may prevent
+ * full-chip retention or off-mode because it is not idle. This
+ * function forces the IVA2 into idle state so it can go
+ * into retention/off and thus allow full-chip retention/off.
+ */
+void __init omap3_prm_force_idle_iva(void)
+{
+ /* ensure IVA2 clock is disabled */
+ omap3_cm_force_iva_clk(false);
+
+ /* if no clock activity, nothing else to do */
+ if (!omap3_cm_is_iva_active())
+ return;
+
+ /* Reset IVA2 */
+ omap2_prm_write_mod_reg(OMAP3430_RST1_IVA2_MASK |
+ OMAP3430_RST2_IVA2_MASK |
+ OMAP3430_RST3_IVA2_MASK,
+ OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
+
+ /* Enable IVA2 clock */
+ omap3_cm_force_iva_clk(true);
+
+ /* Set IVA2 boot mode to 'idle' */
+ omap3_ctrl_set_iva_bootmode_idle();
+
+ /* Un-reset IVA2 */
+ omap2_prm_write_mod_reg(0, OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
+
+ /* Disable IVA2 clock */
+ omap3_cm_force_iva_clk(false);
+
+ /* Reset IVA2 */
+ omap2_prm_write_mod_reg(OMAP3430_RST1_IVA2_MASK |
+ OMAP3430_RST2_IVA2_MASK |
+ OMAP3430_RST3_IVA2_MASK,
+ OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
+}
+
/*
*
*/
diff --git a/arch/arm/mach-omap2/prm3xxx.h b/arch/arm/mach-omap2/prm3xxx.h
index 277f717..1befb23 100644
--- a/arch/arm/mach-omap2/prm3xxx.h
+++ b/arch/arm/mach-omap2/prm3xxx.h
@@ -154,6 +154,8 @@ extern void omap3xxx_prm_restore_irqen(u32 *saved_mask);
extern void omap3xxx_prm_dpll3_reset(void);
+extern void omap3_prm_force_idle_iva(void);
+
extern int __init omap3xxx_prm_init(void);
extern u32 omap3xxx_prm_get_reset_sources(void);
--
1.7.9.5
--
To unsubscribe from this list: send the line
Re: [PATCH] pinctrl: single: call pcs_soc-rearm() whenever IRQ mask is changed
On Fri, Oct 11, 2013 at 6:13 PM, Roger Quadros rog...@ti.com wrote: On OMAPs the IO ring must be rearmed each time the pad wakeup configuration is changed. So call pcs_soc-rearm() from pcs_irq_set(). Signed-off-by: Roger Quadros rog...@ti.com If Tony needs to apply this with the other patches: Acked-by. Yours, Linus Walleij -- 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: OMAP: Device Tree for 3.13
Hi Tony, Please pull the following commits for OMAP Device Tree for v3.13. Thanks, Benoit The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af: Linux 3.12-rc4 (2013-10-06 14:00:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git tags/for_3.13/dts_signed for you to fetch changes up to a778dd01b9ed97af513b53bfaa74039ab5f4b8f2: ARM: dts: omap5-uevm: mark TWL6037 as system-power-controller (2013-10-09 00:37:56 +0200) Add the minimal DTS support for DRA7xx based SoC core. Add the initial support for N900 and gta04 phones. Enable USB3 on OMAP5 evm board. Add support for cryto accelerators Add new IGEP AQUILA board Add AM33XX EDMA support Update HSUSB node to use the reset-gpios fmwk Aaro Koskinen (1): ARM: dts: omap3-devkit8000: fix a typo in GMPC node Afzal Mohammed (2): ARM: dts: AM4372: cpu(s) node per latest binding ARM: dts: AM4372: add few nodes Alexander Holler (1): ARM: dts: am335x-bone: add CD for mmc1 Alexandre Belloni (1): ARM: dts: AM33XX: Add PMU support Balaji T K (2): ARM: dts: am335x-bone-common: correct mux mode for cmd line ARM: dts: am335x-evm[sdk]: switch mmc1 to 4-bit mode Benoit Cousson (1): ARM: OMAP5: hwmod: add missing ocp2scp hwmod data Benoit Parrot (1): ARM: dts: AM33XX: Add LCDC info into am335x-evm Dan Murphy (1): ARM: dts: AM33XX: add ethernet alias's for am33xx Darren Etheridge (1): ARM: dts: AM33XX beagle black: add pinmux and hdmi node to enable display Enric Balletbo i Serra (2): ARM: dts: AM33XX: Add support for IGEP COM AQUILA ARM: dts: AM33XX: Add support for IGEP AQUILA EXPANSION board. Felipe Balbi (2): ARM: dts: OMAP5: add palmas-usb node ARM: configs: omap2plus_defconfig: enable dwc3 and dependencies Javier Martinez Canillas (8): ARM: dts: omap3-igep: add pinmux node for GPIO LED configuration ARM: dts: omap3-igep0020: add mux conf for GPIO LEDs ARM: dts: omap3-igep0030: add mux conf for GPIO LED ARM: dts: AM33XX: use pinmux node defined in included file ARM: dts: AM33XX: don't redefine OCP bus and device nodes ARM: dts: omap3-igep: Add USB OTG support ARM: dts: omap3-igep0020: Add HS USB Host support ARM: dts: omap3-igep0020: use standard constant for IRQ flags Joel Fernandes (5): ARM: dts: OMAP4: Add AES node ARM: dts: OMAP4: Add DES3DES node ARM: dts: AM33XX: Fix AES interrupt number ARM: dts: AM437X: Add AES node ARM: dts: AM437X: Add DES node Keerthy (1): ARM: dts: DRA7: Add TPS659038 PMIC nodes Kishon Vijay Abraham I (1): ARM: dts: omap5-uevm: Split SMPS10 in two nodes Koen Kooi (3): ARM: dts: am335x-boneblack: add eMMC DT entry ARM: dts: am335x-bone-common: switch mmc1 to 4-bit mode ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers Lars Poeschel (1): ARM: dts: AM33xx: Correct gpio #interrupt-cells property Lee Jones (7): ARM: dts: Remove '0x's from OMAP2420 H4 DTS file ARM: dts: Remove '0x's from OMAP3 IGEP0020 DTS file ARM: dts: Remove '0x's from OMAP3 IGEP0030 DTS file ARM: dts: Remove '0x's from OMAP3 DTS file ARM: dts: Remove '0x's from OMAP3430 SDP DTS file ARM: dts: Remove '0x's from OMAP4 DTS file ARM: dts: Remove '0x's from OMAP5 DTS file Marek Belisko (1): ARM: dts: Add devicetree for gta04 board. Mark A. Greer (2): ARM: dts: AM33XX: Add SHAM data and documentation ARM: dts: AM33XX: Add AES data and documentation Matt Porter (3): ARM: dts: AM33XX: Add EDMA support ARM: dts: AM33XX: Add SPI DMA support ARM: dts: AM33XX: Add MMC support and documentation Nishanth Menon (2): ARM: dts: am335x-boneblack: move fixed regulator to board level ARM: dts: omap5-uevm: mark TWL6037 as system-power-controller Pavel Machek (1): ARM: dts: N900: Add device tree R Sricharan (1): ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board Roger Quadros (6): ARM: dts: omap3-beagle: Make USB host pin naming consistent ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset ARM: dts: omap4-panda: Use reset-gpios for hsusb1_reset ARM: dts: omap5-uevm: Use reset-gpios for hsusb2/3_reset ARM: dts: omap3-beagle-xm: Add USB Host support ARM: dts: omap3-beagle: Add USB OTG PHY details Ruslan Bilovol (1): ARM: dts: twl6030: Move common configuration for OMAP4 boards in a separate dtsi file .../devicetree/bindings/crypto/omap-aes.txt| 31 + .../devicetree/bindings/crypto/omap-sham.txt | 28 + .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +- arch/arm/boot/dts/Makefile | 6 +-
Re: [PATCH v2 1/2] ARM: dts: dra7-evm: Add mmc1 node for micro-sd support
On Thursday 10 October 2013 12:21 AM, Sekhar Nori wrote: On Monday 07 October 2013 09:55 PM, Balaji T K wrote: Add mmc1 dt node to dra7-evm board. Input for ldo1 regulator is controlled by gpio 5 of pcf8575 chip (0x21) on i2c1 bus. When dt support for gpio-pcf857x is available, input supply will be modelled as cascaded regulator. Signed-off-by: Balaji T K balaj...@ti.com Acked-by: Sekhar Nori nsek...@ti.com Hi Benoit, Can you let me know if you have any comments on this patch series? Thanks and Regards Balaji T K -- 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+: hwmod changes for v3.13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af: Linux 3.12-rc4 (2013-10-06 14:00:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.13/hwmod for you to fetch changes up to ace1e3ec4a2540c783e65884bb7be9cd45a0a295: ARM: AM33xx: hwmod: Add RNG module data (2013-10-09 09:02:51 -0600) - Some OMAP hwmod changes for 3.13. Significant changes here include: - - support for moving some of the hwmod flags to DT data - - support for the SSI, hardware spinlock, USB host/TLL, and RNG IP blocks for various OMAPs - - a fix that again decouples hwmod data changes from unrelated DT data patchsets Basic test logs are available at: http://www.pwsan.com/omap/testlogs/prcm_fixes_v3.13/20131009094936/ The summary reports that the 4460varsomom boots are failing, but this looks incorrect - it's probably a bug in the validation scripts here. - Lokesh Vutla (1): ARM: AM33xx: hwmod: Add RNG module data Rajendra Nayak (2): ARM: OMAP2+: hwmod: cleanup HWMOD_INIT_NO_RESET usage ARM: OMAP2+: hwmod: Extract no-idle and no-reset info from DT Roger Quadros (1): ARM: OMAP5: hwmod data: Add USB Host and TLL modules Sebastian Reichel (1): ARM: OMAP2+: hwmod data: Add SSI information Suman Anna (3): ARM: OMAP2+: hwmod: check for module address space during init ARM: OMAP5: hwmod data: Add spinlock data ARM: AM33xx: hwmod_data: add the sysc configuration for spinlock arch/arm/mach-omap2/omap_hwmod.c | 49 +--- arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 67 +-- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 48 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 6 +- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 185 - 5 files changed, 325 insertions(+), 30 deletions(-) vmlinux object size (delta in bytes from test_v3.12-rc4 (d0e639c9e06d44e713170031fe05fb60ebe680af)): text data bsstotal kernel 0000 omap1_defconfig 0000 omap1_defconfig_1510innovator_only 0000 omap1_defconfig_5912osk_only +140+11440+1284 omap2plus_defconfig 0000 omap2plus_defconfig_2430sdp_only +140+11680+1308 omap2plus_defconfig_cpupm +12000 +120 omap2plus_defconfig_n800_multi_omap2xxx +12000 +120 omap2plus_defconfig_n800_only_a +140+11760+1316 omap2plus_defconfig_no_pm +4236 +9120+5148 omap2plus_defconfig_omap2_4_only +4236+11760+5412 omap2plus_defconfig_omap3_4_only +228 +184 -96 +316 rmk_omap3430_ldp_allnoconfig +124 +2640 +388 rmk_omap3430_ldp_oldconfig +228 -4 -96 +128 rmk_omap4430_sdp_allnoconfig Boot-time memory difference (delta in bytes from test_v3.12-rc4 (d0e639c9e06d44e713170031fe05fb60ebe680af)) avail rsrvd high freed board kconfig (no differences) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBAgAGBQJSWC5wAAoJEMePsQ0LvSpLs+EP/0XG+FsqgeKnTYCpDtMQahPn kJqMMs4NYjt/zJ0IBHKQ2M0r2QxwvewKOEhyBdP9Z/v5rAbDp8qujSlTJv+Txt8I lowbWCqo1UbpdZHTCb6wf4P50F4s/dfsgIBopVsfnI/UBuALMo+ZzpHSfDIAtkMi aFPEn4tkrDFv/N5jxcF4l+KB6XJumRYv0rK2B+wYxhl0v3szSfpSFCVomjCxgGdw qd/X4CBf/ot3v5F5ePWK8EUHI/nO0xEYnuMNhoK4r3zFYBG+HLrHAW/XECqL/8iT Hcng4PggPLvV3FehsNHJWgNRmW2aiXZbPRS3Zvf0GjxUaQb1GVwz+hJj821rFl2Y AQnDUUmb5c+gvfYlPFrR/VzckZsn14nxnYwZl8gZqFVQbRjyUskBkHRKjKtDsQDW K62aCwbKVsAhyhPmjUUYwmjPM01k/slFvlFAr/puT9Uv6fSIFV2zaAdikOexFY+0 oeTsW94l5POJ24KpfwGY5812KbAyjpulJuFMus4IKFiaZQ5ElEiPAipQJzV1Qv6S FEtzR0BEipXUT5Jp3hKGVbLcJdmJwGpBPhnoXtYGMlAezcq0Hoy5g0hMEPDaY8XW nEJgJdVUlj6Jp6Jva7R5uxAfJxctoXBh1YOBS4HfkT+VP7K1IC4JBpx7mLhThYW6 oFHHRoVthqB0nyF/axHS =pWEm -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] pinctrl: single: call pcs_soc-rearm() whenever IRQ mask is changed
* Roger Quadros rog...@ti.com [131011 09:21]: On OMAPs the IO ring must be rearmed each time the pad wakeup configuration is changed. So call pcs_soc-rearm() from pcs_irq_set(). Signed-off-by: Roger Quadros rog...@ti.com --- drivers/pinctrl/pinctrl-single.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c index c2aada7..1800e47 100644 --- a/drivers/pinctrl/pinctrl-single.c +++ b/drivers/pinctrl/pinctrl-single.c @@ -1604,6 +1604,9 @@ static inline void pcs_irq_set(struct pcs_soc_data *pcs_soc, pcs-write(mask, pcswi-reg); raw_spin_unlock(pcs-lock); } + + if (pcs_soc-rearm) + pcs_soc-rearm(); } /** @@ -1626,8 +1629,6 @@ static void pcs_irq_unmask(struct irq_data *d) struct pcs_soc_data *pcs_soc = irq_data_get_irq_chip_data(d); pcs_irq_set(pcs_soc, d-irq, true); - if (pcs_soc-rearm) - pcs_soc-rearm(); } This seems to cause the wake-up interrupts to happen also during runtime for me, which makes the omap3 behave the same way as omap4 already does. However, the concern I have is that we only want the io chain wake-up happen during idle and not during runtime.. So counting on the io chain in your EHCI driver during runtime would require also additional tracking of idle wake up events vs runtime wake-up events somewhere once we have the automatic solution for runtime PM. That is to avoid spurious interrupts during runtime. In any case, since this is an interrupt controller now, we should just follow the Linux standard for interrupt controllers, so if you do a request_irq() on it, you really should get interrupts. I've updated the patch a litte below to also remove the now bogus comment, and to update the description. So considering all that, I suggest that Linus applies the updated fix below into the pinctrl tree after pulling in the the tag I posted for pinctrl-single-for-linus-for-v3.13-signed. 8 --- From: Roger Quadros rog...@ti.com Date: Fri, 11 Oct 2013 19:13:16 +0300 Subject: [PATCH] pinctrl: single: call pcs_soc-rearm() whenever IRQ mask is changed On OMAPs the IO ring must be rearmed each time the pad wakeup configuration is changed. So call pcs_soc-rearm() from pcs_irq_set(). As pinctrl-single is now an interrupt controller in some cases, we should follow the standards and keep the interrupts enabled constantly, and not just for wake-up events. The tracking of runtime vs wake-up interrupts can be handled separately for the automated runtime PM solution when we have it in the future. Signed-off-by: Roger Quadros rog...@ti.com [t...@atomide.com: removed wrong comment, updated description] Signed-off-by: Tony Lindgren t...@atomide.com --- a/drivers/pinctrl/pinctrl-single.c +++ b/drivers/pinctrl/pinctrl-single.c @@ -1604,6 +1604,9 @@ static inline void pcs_irq_set(struct pcs_soc_data *pcs_soc, pcs-write(mask, pcswi-reg); raw_spin_unlock(pcs-lock); } + + if (pcs_soc-rearm) + pcs_soc-rearm(); } /** @@ -1626,8 +1629,6 @@ static void pcs_irq_unmask(struct irq_data *d) struct pcs_soc_data *pcs_soc = irq_data_get_irq_chip_data(d); pcs_irq_set(pcs_soc, d-irq, true); - if (pcs_soc-rearm) - pcs_soc-rearm(); } /** @@ -1678,11 +1679,6 @@ static int pcs_irq_handle(struct pcs_soc_data *pcs_soc) } } - /* -* For debugging on omaps, you may want to call pcs_soc-rearm() -* here to see wake-up interrupts during runtime also. -*/ - return count; } -- 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] pinctrl: single: call pcs_soc-rearm() whenever IRQ mask is changed
* Linus Walleij linus.wall...@linaro.org [131011 09:27]: On Fri, Oct 11, 2013 at 6:13 PM, Roger Quadros rog...@ti.com wrote: On OMAPs the IO ring must be rearmed each time the pad wakeup configuration is changed. So call pcs_soc-rearm() from pcs_irq_set(). Signed-off-by: Roger Quadros rog...@ti.com If Tony needs to apply this with the other patches: Acked-by. Just replied with a slightly modified version of Roger's patch suggesting you pull in the signed tag I posted for you yesterday and then you can pick up Roger's fix into the pinctrl tree :) 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: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
On Thu, 10 Oct 2013, Tero Kristo wrote: On 10/09/2013 09:59 PM, Paul Walmsley wrote: Eh, one correction: On Wed, 9 Oct 2013, Paul Walmsley wrote: We could easily wind up with kernels that won't boot at all when used with newer DT data. This is a misstatement of the issue: the concern here is that newer kernels may not boot at all with older DT data - which could easily be in locked areas of the flash or firmware. I wonder who would be crazy enough to put DT data into a locked area, and to what purpose. If you can update the kernel, there is no point locking down DT data, this will just cause you unnecessary misery. The DT data will be used by bootloaders also :-( In situations where the bootloaders are signed and locked, the security people are also insisting that the DT data be signed and locked. - 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: [GIT PULL] ARM: OMAP: Device Tree for 3.13
Hi Benoit, * Benoit Cousson bcous...@baylibre.com [131011 09:50]: Add the minimal DTS support for DRA7xx based SoC core. Add the initial support for N900 and gta04 phones. Enable USB3 on OMAP5 evm board. Add support for cryto accelerators Add new IGEP AQUILA board Add AM33XX EDMA support Update HSUSB node to use the reset-gpios fmwk Looks good to me, but we're getting self-inflicted merge conflicts in two places now with Paul's hwmod changes, and my defconfig changes. Can you please respin without the following two patches: 49bcd824c1c0db32fe4de0c1ba3ee36defdb11ca ARM: configs: omap2plus_defconfig: enable dwc3 and dependencies 736c4bb159c793b00331261438deb982cbac3c03 ARM: OMAP5: hwmod: add missing ocp2scp hwmod data I can pick the two patches above and apply after pulling in Paul's branch first. However, if other branches are based on this, then we just need to deal with the merge conflicts, and there's no point in redoing your branch. 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 v8 6/6] mtd: nand: omap: updated devm_xx for all resource allocation and free calls
Hi Pekon,
On Fri, Oct 11, 2013 at 07:06:43PM +0530, Pekon Gupta wrote:
Managed Device Resource or devm_xx calls takes care of automatic freeing
of the resource in case of:
- failure during driver probe
- failure during resource allocation
- detaching or unloading of driver module (rmmod)
Reference: Documentation/driver-model/devres.txt
Though OMAP NAND driver handles freeing of resource allocation in most of
the cases, but using devm_xx provides more clean and effortless approach
to handle all such cases.
Judging by your patch, I think you missed the point of the devm_*
managed functions. They are useful because you don't need to do any of
the cleanup (kfree(), iounmap(), etc.) yourself. I'll note the changes
that are necessary below, but seeing as this is an add-on to your patch
series, I may merge the rest of series without this, and if so, you can
just resubmit this patch separately.
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/omap2.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index a783dae..0f2b0d1 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1658,7 +1658,8 @@ static int omap_nand_probe(struct platform_device *pdev)
return -ENODEV;
}
- info = kzalloc(sizeof(struct omap_nand_info), GFP_KERNEL);
+ info = devm_kzalloc(pdev-dev, sizeof(struct omap_nand_info),
+ GFP_KERNEL);
if (!info)
return -ENOMEM;
@@ -1690,13 +1691,14 @@ static int omap_nand_probe(struct platform_device
*pdev)
info-phys_base = res-start;
info-mem_size = resource_size(res);
- if (!request_mem_region(info-phys_base, info-mem_size,
- pdev-dev.driver-name)) {
+ if (!devm_request_mem_region(pdev-dev, info-phys_base,
+ info-mem_size, pdev-dev.driver-name)) {
err = -EBUSY;
goto out_free_info;
}
- info-nand.IO_ADDR_R = ioremap(info-phys_base, info-mem_size);
+ info-nand.IO_ADDR_R = devm_ioremap(pdev-dev, info-phys_base,
+ info-mem_size);
if (!info-nand.IO_ADDR_R) {
err = -ENOMEM;
goto out_release_mem_region;
@@ -1799,8 +1801,9 @@ static int omap_nand_probe(struct platform_device *pdev)
err = -ENODEV;
goto out_release_mem_region;
}
- err = request_irq(info-gpmc_irq_fifo, omap_nand_irq,
- IRQF_SHARED, gpmc-nand-fifo, info);
+ err = devm_request_irq(pdev-dev, info-gpmc_irq_fifo,
+ omap_nand_irq, IRQF_SHARED,
+ gpmc-nand-fifo, info);
if (err) {
dev_err(pdev-dev, requesting irq(%d) error:%d,
info-gpmc_irq_fifo, err);
@@ -1814,8 +1817,9 @@ static int omap_nand_probe(struct platform_device *pdev)
err = -ENODEV;
goto out_release_mem_region;
}
- err = request_irq(info-gpmc_irq_count, omap_nand_irq,
- IRQF_SHARED, gpmc-nand-count, info);
+ err = devm_request_irq(pdev-dev, info-gpmc_irq_count,
+ omap_nand_irq, IRQF_SHARED,
+ gpmc-nand-count, info);
if (err) {
dev_err(pdev-dev, requesting irq(%d) error:%d,
info-gpmc_irq_count, err);
@@ -2031,10 +2035,10 @@ out_release_mem_region:
if (info-dma)
dma_release_channel(info-dma);
if (info-gpmc_irq_count 0)
- free_irq(info-gpmc_irq_count, info);
+ devm_free_irq(pdev-dev, info-gpmc_irq_count, info);
Just drop the 'free'.
if (info-gpmc_irq_fifo 0)
- free_irq(info-gpmc_irq_fifo, info);
- release_mem_region(info-phys_base, info-mem_size);
+ devm_free_irq(pdev-dev, info-gpmc_irq_fifo, info);
Drop the 'free'.
+ devm_release_mem_region(pdev-dev, info-phys_base, info-mem_size);
Drop this line.
out_free_info:
#ifdef CONFIG_MTD_NAND_ECC_BCH
if (info-nand.ecc.priv) {
@@ -2042,7 +2046,7 @@ out_free_info:
info-nand.ecc.priv = NULL;
}
#endif
- kfree(info);
+ devm_kfree(pdev-dev, info);
This line is also not needed.
So in the end, the 'gotos' and error path of your probe function will be
much simpler. You will only need to manage the info-dma DMA channel
(i.e., dma_release_channel()).
return err;
}
@@ -2062,15 +2066,15 @@ static int omap_nand_remove(struct platform_device
*pdev)
Re: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
On 10/11/2013 08:54 PM, Paul Walmsley wrote: On Thu, 10 Oct 2013, Tero Kristo wrote: On 10/09/2013 09:59 PM, Paul Walmsley wrote: Eh, one correction: On Wed, 9 Oct 2013, Paul Walmsley wrote: We could easily wind up with kernels that won't boot at all when used with newer DT data. This is a misstatement of the issue: the concern here is that newer kernels may not boot at all with older DT data - which could easily be in locked areas of the flash or firmware. I wonder who would be crazy enough to put DT data into a locked area, and to what purpose. If you can update the kernel, there is no point locking down DT data, this will just cause you unnecessary misery. The DT data will be used by bootloaders also :-( In situations where the bootloaders are signed and locked, the security people are also insisting that the DT data be signed and locked. Well, even if you sign something, you can still update it. Writing any software to true OTP memory is one way to commit suicide IMO. How many nasty bugs have you seen with ROM code? Also, if people want to make their custom security solutions which are not supported by the kernel, why should the kernel care about it? We don't know the details, and can't influence the design, so we can't prepare for it anyway. -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: [PATCH v8 6/6] mtd: nand: omap: updated devm_xx for all resource allocation and free calls
* Brian Norris computersforpe...@gmail.com [131011 11:23]: Hi Pekon, On Fri, Oct 11, 2013 at 07:06:43PM +0530, Pekon Gupta wrote: Managed Device Resource or devm_xx calls takes care of automatic freeing of the resource in case of: - failure during driver probe - failure during resource allocation - detaching or unloading of driver module (rmmod) Reference: Documentation/driver-model/devres.txt Though OMAP NAND driver handles freeing of resource allocation in most of the cases, but using devm_xx provides more clean and effortless approach to handle all such cases. Judging by your patch, I think you missed the point of the devm_* managed functions. They are useful because you don't need to do any of the cleanup (kfree(), iounmap(), etc.) yourself. I'll note the changes that are necessary below, but seeing as this is an add-on to your patch series, I may merge the rest of series without this, and if so, you can just resubmit this patch separately. FYI, the .dts changes should be queued separately by Benoit to avoid pointless merge conflicts. The arch/arm/mach-omap2/gpmc.c changes I need to look, hopefully I can ack those for you today so you can take the code related changes into the MTD tree. 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 v8 2/6] ARM: OMAP2+: cleaned-up DT support of various ECC schemes
* Felipe Balbi ba...@ti.com [131011 09:03]: On Fri, Oct 11, 2013 at 07:06:39PM +0530, Pekon Gupta wrote: OMAP NAND driver support multiple ECC scheme, which can used in following different flavours, depending on in-build Hardware engines supported by SoC. +---+---+---+ | ECC scheme|ECC calculation|Error detection| +---+---+---+ |OMAP_ECC_HAM1_CODE_HW |H/W (GPMC) |S/W| +---+---+---+ |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W| |(requires CONFIG_MTD_NAND_ECC_BCH) | | | +---+---+---+ |OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) | |(requires CONFIG_MTD_NAND_OMAP_BCH | | | | ti,elm-id in DT) | | | +---+---+---+ To optimize footprint of omap2-nand driver, selection of some ECC schemes also require enabling following Kconfigs, in addition to setting appropriate DT bindings - Kconfig:CONFIG_MTD_NAND_ECC_BCHerror detection done in software - Kconfig:CONFIG_MTD_NAND_OMAP_BCH error detection done by h/w engine DT binding updates in this patch are: - ti,elm-id: replaces elm_id - ti,nand-ecc-opts: supported values ham1, bch4, and bch8 selection of h/w or s/w implementation depends on ti,elm-id Signed-off-by: Pekon Gupta pe...@ti.com since this maintains backwards compatibility, I think it should be alright to apply Reviewed-by: Felipe Balbi ba...@ti.com This patch looks safe to queue via the MTD tree for the arch/arm/*omap* parts in this patch: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 1/6] mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes
* Felipe Balbi ba...@ti.com [131011 09:04]: On Fri, Oct 11, 2013 at 07:06:38PM +0530, Pekon Gupta wrote: OMAP NAND driver currently supports multiple flavours of 1-bit Hamming ecc-scheme, like: - OMAP_ECC_HAMMING_CODE_DEFAULT 1-bit hamming ecc code using software library - OMAP_ECC_HAMMING_CODE_HW 1-bit hamming ecc-code using GPMC h/w engine - OMAP_ECC_HAMMING_CODE_HW_ROMCODE 1-bit hamming ecc-code using GPMC h/w engin with ecc-layout compatible to ROM code. This patch combines above multiple ecc-schemes into single implementation: - OMAP_ECC_HAM1_CODE_HW 1-bit hamming ecc-code using GPMC h/w engine with ROM-code compatible ecc-layout. Signed-off-by: Pekon Gupta pe...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com This one looks safe to queue via the MTD tree for the arch/arm/*omap* parts: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
On 10/11/2013 08:54 PM, Paul Walmsley wrote: On Thu, 10 Oct 2013, Tero Kristo wrote: On 10/09/2013 09:59 PM, Paul Walmsley wrote: Eh, one correction: On Wed, 9 Oct 2013, Paul Walmsley wrote: We could easily wind up with kernels that won't boot at all when used with newer DT data. This is a misstatement of the issue: the concern here is that newer kernels may not boot at all with older DT data - which could easily be in locked areas of the flash or firmware. I wonder who would be crazy enough to put DT data into a locked area, and to what purpose. If you can update the kernel, there is no point locking down DT data, this will just cause you unnecessary misery. The DT data will be used by bootloaders also :-( In situations where the bootloaders are signed and locked, the security people are also insisting that the DT data be signed and locked. Oh yea, one additional note you probably have missed. Mike asked us to fall back to vendor specific bindings at around v6 or so of this set. Take a look at v8, we have dropped the use of generic bindings, we are not trying to declare those with this set. This set introduces vendor specific bindings only, and even these are claimed 'unstable', which should be enough to discourage people from burning those to OTP type memory. -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: [GIT PULL] ARM: OMAP: Device Tree for 3.13
Hi Tony, On 11/10/2013 20:03, Tony Lindgren wrote: Hi Benoit, * Benoit Cousson bcous...@baylibre.com [131011 09:50]: Add the minimal DTS support for DRA7xx based SoC core. Add the initial support for N900 and gta04 phones. Enable USB3 on OMAP5 evm board. Add support for cryto accelerators Add new IGEP AQUILA board Add AM33XX EDMA support Update HSUSB node to use the reset-gpios fmwk Looks good to me, but we're getting self-inflicted merge conflicts in two places now with Paul's hwmod changes, and my defconfig changes. Damn! Can you please respin without the following two patches: 49bcd824c1c0db32fe4de0c1ba3ee36defdb11ca ARM: configs: omap2plus_defconfig: enable dwc3 and dependencies 736c4bb159c793b00331261438deb982cbac3c03 ARM: OMAP5: hwmod: add missing ocp2scp hwmod data I can pick the two patches above and apply after pulling in Paul's branch first. OK, no problem. However, if other branches are based on this, then we just need to deal with the merge conflicts, and there's no point in redoing your branch. Considering the patches, I don't see any dependency with the other ones, as soon as they are pulled before the DTS changes. I'll do that ASAP and repost. Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: dts: dra7-evm: Add mmc1 node for micro-sd support
Hi Balaji, On 11/10/2013 18:44, Balaji T K wrote: On Thursday 10 October 2013 12:21 AM, Sekhar Nori wrote: On Monday 07 October 2013 09:55 PM, Balaji T K wrote: Add mmc1 dt node to dra7-evm board. Input for ldo1 regulator is controlled by gpio 5 of pcf8575 chip (0x21) on i2c1 bus. When dt support for gpio-pcf857x is available, input supply will be modelled as cascaded regulator. Signed-off-by: Balaji T K balaj...@ti.com Acked-by: Sekhar Nori nsek...@ti.com Hi Benoit, Can you let me know if you have any comments on this patch series? The series looks good, and I've just applied it for 3.13. Thanks, Benoit -- 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: OMAP: Device Tree for 3.13, take #2
Hi Tony, Please pull the updated branch for OMAP Device Tree for v3.13. I removed the 2 conflicting patches, and added 2 mores for dra7 to compensate :-) Thanks, Benoit The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af: Linux 3.12-rc4 (2013-10-06 14:00:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git tags/for_3.13/dts_signed for you to fetch changes up to 6cf02dbb4b71f1c0c9acec89ae2df3b2318135f4: ARM: dts: dra7-evm: Add mmc2 node for eMMC support (2013-10-11 21:15:02 +0200) Add the minimal DTS support for DRA7xx based SoC core. Add the initial support for N900 and gta04 phones. Enable USB3 on OMAP5 evm board. Add support for cryto accelerators Add new IGEP AQUILA board Add AM33XX EDMA support Update HSUSB node to use the reset-gpios fmwk Aaro Koskinen (1): ARM: dts: omap3-devkit8000: fix a typo in GMPC node Afzal Mohammed (2): ARM: dts: AM4372: cpu(s) node per latest binding ARM: dts: AM4372: add few nodes Alexander Holler (1): ARM: dts: am335x-bone: add CD for mmc1 Alexandre Belloni (1): ARM: dts: AM33XX: Add PMU support Balaji T K (4): ARM: dts: am335x-bone-common: correct mux mode for cmd line ARM: dts: am335x-evm[sdk]: switch mmc1 to 4-bit mode ARM: dts: dra7-evm: Add mmc1 node for micro-sd support ARM: dts: dra7-evm: Add mmc2 node for eMMC support Benoit Parrot (1): ARM: dts: AM33XX: Add LCDC info into am335x-evm Dan Murphy (1): ARM: dts: AM33XX: add ethernet alias's for am33xx Darren Etheridge (1): ARM: dts: AM33XX beagle black: add pinmux and hdmi node to enable display Enric Balletbo i Serra (2): ARM: dts: AM33XX: Add support for IGEP COM AQUILA ARM: dts: AM33XX: Add support for IGEP AQUILA EXPANSION board. Felipe Balbi (1): ARM: dts: OMAP5: add palmas-usb node Javier Martinez Canillas (8): ARM: dts: omap3-igep: add pinmux node for GPIO LED configuration ARM: dts: omap3-igep0020: add mux conf for GPIO LEDs ARM: dts: omap3-igep0030: add mux conf for GPIO LED ARM: dts: AM33XX: use pinmux node defined in included file ARM: dts: AM33XX: don't redefine OCP bus and device nodes ARM: dts: omap3-igep: Add USB OTG support ARM: dts: omap3-igep0020: Add HS USB Host support ARM: dts: omap3-igep0020: use standard constant for IRQ flags Joel Fernandes (5): ARM: dts: OMAP4: Add AES node ARM: dts: OMAP4: Add DES3DES node ARM: dts: AM33XX: Fix AES interrupt number ARM: dts: AM437X: Add AES node ARM: dts: AM437X: Add DES node Keerthy (1): ARM: dts: DRA7: Add TPS659038 PMIC nodes Kishon Vijay Abraham I (1): ARM: dts: omap5-uevm: Split SMPS10 in two nodes Koen Kooi (3): ARM: dts: am335x-boneblack: add eMMC DT entry ARM: dts: am335x-bone-common: switch mmc1 to 4-bit mode ARM: dts: am335x-bone-common: add cpu0 and mmc1 triggers Lars Poeschel (1): ARM: dts: AM33xx: Correct gpio #interrupt-cells property Lee Jones (7): ARM: dts: Remove '0x's from OMAP2420 H4 DTS file ARM: dts: Remove '0x's from OMAP3 IGEP0020 DTS file ARM: dts: Remove '0x's from OMAP3 IGEP0030 DTS file ARM: dts: Remove '0x's from OMAP3 DTS file ARM: dts: Remove '0x's from OMAP3430 SDP DTS file ARM: dts: Remove '0x's from OMAP4 DTS file ARM: dts: Remove '0x's from OMAP5 DTS file Marek Belisko (1): ARM: dts: Add devicetree for gta04 board. Mark A. Greer (2): ARM: dts: AM33XX: Add SHAM data and documentation ARM: dts: AM33XX: Add AES data and documentation Matt Porter (3): ARM: dts: AM33XX: Add EDMA support ARM: dts: AM33XX: Add SPI DMA support ARM: dts: AM33XX: Add MMC support and documentation Nishanth Menon (2): ARM: dts: am335x-boneblack: move fixed regulator to board level ARM: dts: omap5-uevm: mark TWL6037 as system-power-controller Pavel Machek (1): ARM: dts: N900: Add device tree R Sricharan (1): ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board Roger Quadros (6): ARM: dts: omap3-beagle: Make USB host pin naming consistent ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset ARM: dts: omap4-panda: Use reset-gpios for hsusb1_reset ARM: dts: omap5-uevm: Use reset-gpios for hsusb2/3_reset ARM: dts: omap3-beagle-xm: Add USB Host support ARM: dts: omap3-beagle: Add USB OTG PHY details Ruslan Bilovol (1): ARM: dts: twl6030: Move common configuration for OMAP4 boards in a separate dtsi file .../devicetree/bindings/crypto/omap-aes.txt| 31 + .../devicetree/bindings/crypto/omap-sham.txt | 28 + .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 26 +- arch/arm/boot/dts/Makefile |
Re: [PATCH v8 6/6] mtd: nand: omap: updated devm_xx for all resource allocation and free calls
On Fri, Oct 11, 2013 at 11:28 AM, Tony Lindgren t...@atomide.com wrote: * Brian Norris computersforpe...@gmail.com [131011 11:23]: Hi Pekon, On Fri, Oct 11, 2013 at 07:06:43PM +0530, Pekon Gupta wrote: Managed Device Resource or devm_xx calls takes care of automatic freeing of the resource in case of: - failure during driver probe - failure during resource allocation - detaching or unloading of driver module (rmmod) Reference: Documentation/driver-model/devres.txt Though OMAP NAND driver handles freeing of resource allocation in most of the cases, but using devm_xx provides more clean and effortless approach to handle all such cases. Judging by your patch, I think you missed the point of the devm_* managed functions. They are useful because you don't need to do any of the cleanup (kfree(), iounmap(), etc.) yourself. I'll note the changes that are necessary below, but seeing as this is an add-on to your patch series, I may merge the rest of series without this, and if so, you can just resubmit this patch separately. FYI, the .dts changes should be queued separately by Benoit to avoid pointless merge conflicts. The arch/arm/mach-omap2/gpmc.c changes I need to look, hopefully I can ack those for you today so you can take the code related changes into the MTD tree. Why are you replying to this patch, instead of the DTS? Also, I don't think all of this code is ready. There are several comments from weeks ago that Pekon hasn't addressed. It's possible the DT binding changes can go in, but not some of the later patches, yet. Brian -- 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 v8 3/6] mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe
On Fri, Oct 11, 2013 at 07:06:40PM +0530, Pekon Gupta wrote: OMAP NAND driver support multiple ECC scheme, which can used in following different flavours, depending on in-build Hardware engines supported by SoC. +---+---+---+ | ECC scheme|ECC calculation|Error detection| +---+---+---+ |OMAP_ECC_HAM1_CODE_HW |H/W (GPMC) |S/W| +---+---+---+ |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W| |(requires CONFIG_MTD_NAND_ECC_BCH) | | | +---+---+---+ |OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) | |(requires CONFIG_MTD_NAND_OMAP_BCH | | | | ti,elm-id in DT) | | | +---+---+---+ To optimize footprint of omap2-nand driver, selection of some ECC schemes also require enabling following Kconfigs, in addition to setting appropriate DT bindings - Kconfig:CONFIG_MTD_NAND_ECC_BCHenables S/W based BCH ECC algorithm - Kconfig:CONFIG_MTD_NAND_OMAP_BCH enables H/W based BCH ECC algorithm This patch - separates the configurations code for each ECC schemes - fixes dependency issues based on Kconfig options - updates ELM device detection in is_elm_present() - cleans redundant code I'll repeat my previous comment on this patch, since it seems entirely ignored: quote [this patch] ... does too many unrelated things in a single patch. I am not comfortable taking large amounts of refactoring mixed in with Kconfig and #ifdef changes. Can you please separate the steps you list below into multiple patches and describe each one? I think you are doing many trivial things, but it's difficult to separate the noise out from the substantial changes. /quote Considering your frustration, it is certainly in your best interest to make your patches more easily reviewable and to address my comments when I make them. I cannot sign off on your patches in the current state, and you have failed to properly address my comments on the nearly identical code from weeks ago. Please, put more effort into splitting your patches into reviewable chunks and into writing *good* descriptions -- right now, 90% of your commit message consists of a repeated ECC table, which does not actually describe your changes. The remaining description is a jumble of multiple unrelated thoughts, reflecting the similarly confusing patches. A similar criticism applies to your other patches, whose descriptions do not adequately reflect their contents. Signed-off-by: Pekon Gupta pe...@ti.com --- drivers/mtd/nand/omap2.c | 450 +++ 1 file changed, 220 insertions(+), 230 deletions(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 8d521aa..fb96251 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -25,8 +25,10 @@ #include linux/of.h #include linux/of_device.h -#ifdef CONFIG_MTD_NAND_OMAP_BCH +#ifdef CONFIG_MTD_NAND_ECC_BCH #include linux/bch.h +#endif +#ifdef CONFIG_MTD_NAND_OMAP_BCH #include linux/platform_data/elm.h #endif Why do you even need the #ifdef's for the #include's? It is not harmful to include headers for stuff that is only conditionally used. In fact, this creates a problem later when you try to use nand_bch_free(), and you have to surround it with extra #ifdef's. In short: these #ifdef's just breed more #ifdef's and cause the code to become harder to read and less maintainable. (I commented about the #ifdef's around nand_bch_free() in v6, and you did not address the comment.) @@ -1846,20 +1726,18 @@ static int omap_nand_probe(struct platform_device *pdev) spin_lock_init(info-controller.lock); init_waitqueue_head(info-controller.wq); - info-pdev = pdev; - + mtd = info-mtd; + mtd-name = dev_name(pdev-dev); + mtd-owner = THIS_MODULE; + mtd-priv = info-nand; + nand_chip = info-nand; + info-pdev = pdev; info-gpmc_cs = pdata-cs; info-reg = pdata-reg; + info-bch = NULL; - info-mtd.priv = info-nand; - info-mtd.name = dev_name(pdev-dev); - info-mtd.owner = THIS_MODULE; - - info-nand.options = pdata-devsize; - info-nand.options |= NAND_SKIP_BBTSCAN; -#ifdef CONFIG_MTD_NAND_OMAP_BCH + nand_chip-options |= NAND_SKIP_BBTSCAN | NAND_BUSWIDTH_AUTO; I recommended (in v6) you split the NAND_BUSWIDTH_AUTO change to a new patch and to
Re: [PATCH] ARM: DRA: DTS: Remove clock-frequency field for cpu timers
Hi Sricharan, On 10/10/2013 15:11, Santosh Shilimkar wrote: On Thursday 10 October 2013 03:50 AM, Sricharan R wrote: The arm arch timers frequency are now programmed in the CNTFREQ per-cpu register by the timer code using the secure API [1]. So remove the redundant entry from the dts. [1] http://marc.info/?l=linux-omapm=138139106312786w=2 Cc: Benoit Cousson bcous...@baylibre.com Signed-off-by: Sricharan R r.sricha...@ti.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com I've just applied it for 3.13. Thanks, Benoit -- 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 v8 4/6] mtd:nand:omap2: updated support for BCH4 ECC scheme
On Fri, Oct 11, 2013 at 07:06:41PM +0530, Pekon Gupta wrote:
This patch adds following two flavours of BCH4 ECC scheme in omap2-nand driver
- OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
- uses GPMC H/W engine for calculating ECC.
- uses software library (lib/bch.h nand_bch.h) for error correction.
- OMAP_ECC_BCH4_CODE_HW
- uses GPMC H/W engine for calculating ECC.
- uses ELM H/W engine for error correction.
With this patch omap2-nand driver supports following ECC schemes:
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAM1_CODE_HW |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)|
|OMAP_ECC_BCH4_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)|
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
Important:
- Selection of OMAP_ECC_BCHx_CODE_HW_DETECTION_SW requires,
Kconfig: CONFIG_MTD_NAND_ECC_BCH: enables S/W based BCH ECC algorithm.
- Selection of OMAP_ECC_BCHx_CODE_HW requires,
Kconfig: CONFIG_MTD_NAND_OMAP_BCH: enables ELM H/W module.
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/Kconfig | 30 ++-
drivers/mtd/nand/omap2.c | 134
+--
2 files changed, 63 insertions(+), 101 deletions(-)
...
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index fb96251..a783dae 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1927,7 +1868,7 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip-ecc.bytes= 7;
nand_chip-ecc.strength = 4;
nand_chip-ecc.hwctl= omap3_enable_hwecc_bch;
- nand_chip-ecc.correct = omap3_correct_data_bch;
+ info-nand.ecc.correct = nand_bch_correct_data;
Your patch description doesn't talk about this (and the deletion of
omap3_correct_data_bch() above). Is the NAND BCH library a drop-in
replacement for omap3_correct_data_bch()? If so, TELL me about it in the
commit description. If not, this is an incompatible change and should at
least be documented so that people can understand the change. These
questions are being asked by the DT guys, so include it in your
descriptions.
Also, you're very inconsistent on using 'nand_chip' vs. 'info-nand'.
You added 'nand_chip' amid the noise of patch 3, so if you have it, use
it consistently throughout probe(). Or remove it and don't use it at
all. (This would be an independent patch from patch 3 and 4, in case
you're wondering, since it causes a lot of diff noise.)
nand_chip-ecc.calculate= omap3_calculate_ecc_bch4;
/* define custom ECC layout */
ecclayout-eccbytes = nand_chip-ecc.bytes *
@@ -2061,7 +2036,12 @@ out_release_mem_region:
free_irq(info-gpmc_irq_fifo, info);
release_mem_region(info-phys_base, info-mem_size);
out_free_info:
- omap3_free_bch(info-mtd);
+#ifdef CONFIG_MTD_NAND_ECC_BCH
+ if (info-nand.ecc.priv) {
+ nand_bch_free(info-nand.ecc.priv);
+ info-nand.ecc.priv = NULL;
+ }
+#endif
As noted previously, the #ifdef should not be necessary.
kfree(info);
return err;
@@ -2072,8 +2052,12 @@ static int omap_nand_remove(struct platform_device
*pdev)
struct mtd_info *mtd = platform_get_drvdata(pdev);
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
- omap3_free_bch(info-mtd);
-
+#ifdef CONFIG_MTD_NAND_ECC_BCH
+ if (info-nand.ecc.priv) {
+ nand_bch_free(info-nand.ecc.priv);
+ info-nand.ecc.priv = NULL;
+ }
+#endif
Ditto.
if (info-dma)
dma_release_channel(info-dma);
Brian
--
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 v8 0/6] mtd:nand:omap2: clean-up of supported ECC schemes
Hi Pekon,
I will try to summarize the standing of your patch series.
Patches 1 and 2 look good and have addressed all of the DT maintainers'
comments, AFAICT. They are ready to go in, except that the following
patches are not ready; they should probably go in together.
You ignored most of my comments to patch 3, and it is insufficiently
documented. Please take a look at my comments, both here (in v8) and in
v6. It still should be split into more patches.
Patch 4 does too much without describing it. Why are you dropping the
old omap3_correct_data_bch() code? Is this just refactoring? If so, you
should say so. And this also suggests that you have two logical changes
going on that should be separated into different patches; one to
refactor the open-coded NAND/BCH library to replace it with the
nand_bch.{c,h} support library and one for the new ECC modes.
Patch 5 is good but should wait until the other DT parts are acceptable
and merged into MTD.
Patch 6 needs rewriting to use devm_* functions properly, but it was
never integral to this patch series. You can improve it and resend with
this series or just send it separately afterward.
On Fri, Oct 11, 2013 at 07:06:37PM +0530, Pekon Gupta wrote:
*Changes v7 - v8*
[PATCH 1/6] no updates
[PATCH 2/6]
- updated DT parsing of ti,nand-ecc-opts so that its ham1 remains
compatible to sw,hw,hw-romcode
- updated DT parsing of ti,elm-id to retain compatibility to elm_id
- using of_parse_phandle() to get ELM device pointer from DT
[PATCH 3..6/6] commit log updates
*Changes v6 - v7*
[PATCH 1/6] NEW split from [PATCH v6 2/4] as per feedbacks of Brain Norris
[PATCH 2/6] incorporated feedbacks from DT maintainers
[PATCH 3/6] patch cleaning and incorporated feedbacks from Brain Norris
You did not incorporate most of my feedback here. Also, my name is
'Brian' not 'Brain', although I'm flattered ;)
[PATCH 4/6] rebasing changes and cleanup
[PATCH 5/6] updated omap3430-sdp.dts
[PATCH 6/6] NEW updated for devm_xx
...
After this patch series, omap2-nand driver will supports following ECC
schemes:
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAM1_CODE_HW |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)|
|OMAP_ECC_BCH4_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.h)|
|OMAP_ECC_BCH8_CODE_HW |H/W (GPMC) |H/W (ELM) |
+---+---+---+
To optimize footprint of omap2-nand driver, selection of some ECC schemes
also require enabling following Kconfigs, in addition to setting appropriate
DT bindings
- Kconfig:CONFIG_MTD_NAND_ECC_BCHerror detection done in software
- Kconfig:CONFIG_MTD_NAND_OMAP_BCH error detection done by h/w engine
Pekon Gupta (6):
mtd: nand: omap: combine different flavours of 1-bit hamming ecc
schemes
ARM: OMAP2+: cleaned-up DT support of various ECC schemes
mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in
device_probe
mtd:nand:omap2: updated support for BCH4 ECC scheme
ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt
mtd: nand: omap: updated devm_xx for all resource allocation and free
calls
.../devicetree/bindings/mtd/gpmc-nand.txt | 16 +-
arch/arm/boot/dts/am335x-evm.dts | 3 +-
arch/arm/boot/dts/omap3430-sdp.dts | 2 +-
arch/arm/mach-omap2/board-flash.c | 2 +-
arch/arm/mach-omap2/gpmc.c | 47 +-
drivers/mtd/nand/Kconfig | 30 +-
drivers/mtd/nand/omap2.c | 569
++---
include/linux/platform_data/mtd-nand-omap2.h | 18 +-
8 files changed, 333 insertions(+), 354 deletions(-)
Brian
--
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: [GIT PULL] ARM: OMAP: Device Tree for 3.13
* Benoit Cousson bcous...@baylibre.com [131011 12:13]: Hi Tony, On 11/10/2013 20:03, Tony Lindgren wrote: Hi Benoit, * Benoit Cousson bcous...@baylibre.com [131011 09:50]: Add the minimal DTS support for DRA7xx based SoC core. Add the initial support for N900 and gta04 phones. Enable USB3 on OMAP5 evm board. Add support for cryto accelerators Add new IGEP AQUILA board Add AM33XX EDMA support Update HSUSB node to use the reset-gpios fmwk Looks good to me, but we're getting self-inflicted merge conflicts in two places now with Paul's hwmod changes, and my defconfig changes. Damn! :) Can you please respin without the following two patches: 49bcd824c1c0db32fe4de0c1ba3ee36defdb11ca ARM: configs: omap2plus_defconfig: enable dwc3 and dependencies 736c4bb159c793b00331261438deb982cbac3c03 ARM: OMAP5: hwmod: add missing ocp2scp hwmod data I can pick the two patches above and apply after pulling in Paul's branch first. OK, no problem. However, if other branches are based on this, then we just need to deal with the merge conflicts, and there's no point in redoing your branch. Considering the patches, I don't see any dependency with the other ones, as soon as they are pulled before the DTS changes. I'll do that ASAP and repost. OK thanks! I'll cherry pick the above two commits then. 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 v8 6/6] mtd: nand: omap: updated devm_xx for all resource allocation and free calls
* Brian Norris computersforpe...@gmail.com [131011 12:35]: On Fri, Oct 11, 2013 at 11:28 AM, Tony Lindgren t...@atomide.com wrote: FYI, the .dts changes should be queued separately by Benoit to avoid pointless merge conflicts. The arch/arm/mach-omap2/gpmc.c changes I need to look, hopefully I can ack those for you today so you can take the code related changes into the MTD tree. Why are you replying to this patch, instead of the DTS? Because you said you might merrge some parts of the series and I've seen many merge cycles of pointless merge conflicts with driver maintainers merging .dts files along with the driver changes? :) Pekon, can please post the .dts changes entirely separately from the driver changes in the future? Also, I don't think all of this code is ready. There are several comments from weeks ago that Pekon hasn't addressed. It's possible the DT binding changes can go in, but not some of the later patches, yet. Yes that's up to you. I have not looked at the MTD parts and I appreciate the fact that you are reviewing that stuff. I've acked the arch/arm/*omap* parts so hopefully I'm out of the loop now. 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 v8 6/6] mtd: nand: omap: updated devm_xx for all resource allocation and free calls
On Fri, Oct 11, 2013 at 2:46 PM, Tony Lindgren t...@atomide.com wrote: * Brian Norris computersforpe...@gmail.com [131011 12:35]: On Fri, Oct 11, 2013 at 11:28 AM, Tony Lindgren t...@atomide.com wrote: FYI, the .dts changes should be queued separately by Benoit to avoid pointless merge conflicts. The arch/arm/mach-omap2/gpmc.c changes I need to look, hopefully I can ack those for you today so you can take the code related changes into the MTD tree. Why are you replying to this patch, instead of the DTS? Because you said you might merrge some parts of the series and I've seen many merge cycles of pointless merge conflicts with driver maintainers merging .dts files along with the driver changes? :) Sure, thanks for pointing this out. I may have fallen into that myself. Pekon, can please post the .dts changes entirely separately from the driver changes in the future? Also, I don't think all of this code is ready. There are several comments from weeks ago that Pekon hasn't addressed. It's possible the DT binding changes can go in, but not some of the later patches, yet. Yes that's up to you. I have not looked at the MTD parts and I appreciate the fact that you are reviewing that stuff. I've acked the arch/arm/*omap* parts so hopefully I'm out of the loop now. Yes, I think so. The MTD stuff is the only remaining weak point I see. Brian -- 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: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
On Fri, 11 Oct 2013, Tero Kristo wrote: Well, even if you sign something, you can still update it. Writing any software to true OTP memory is one way to commit suicide IMO. How many nasty bugs have you seen with ROM code? Also, if people want to make their custom security solutions which are not supported by the kernel, why should the kernel care about it? We don't know the details, and can't influence the design, so we can't prepare for it anyway. The point is that newer kernels need to be compatible with older DT data: that's the stable ABI criterion that's been discussed quite a bit. The worst-case scenario if the bindings are at a top-level node and not fully cooked is that it can make it very difficult, if not impossible, to have this forward compatibility for the DT data without having extremely nasty hacks. - 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: [GIT PULL] ARM: OMAP2+: hwmod changes for v3.13
* Paul Walmsley p...@pwsan.com [131011 10:08]: Hi Tony, The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af: Linux 3.12-rc4 (2013-10-06 14:00:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.13/hwmod for you to fetch changes up to ace1e3ec4a2540c783e65884bb7be9cd45a0a295: ARM: AM33xx: hwmod: Add RNG module data (2013-10-09 09:02:51 -0600) Some OMAP hwmod changes for 3.13. Significant changes here include: - support for moving some of the hwmod flags to DT data - support for the SSI, hardware spinlock, USB host/TLL, and RNG IP blocks for various OMAPs - a fix that again decouples hwmod data changes from unrelated DT data patchsets Basic test logs are available at: http://www.pwsan.com/omap/testlogs/prcm_fixes_v3.13/20131009094936/ The summary reports that the 4460varsomom boots are failing, but this looks incorrect - it's probably a bug in the validation scripts here. OK I'll do a test on my panda es before sending out the branches and will apply that one hwmod patch Benoit had queued on top of this. So pulling into omap-for-v3.13/hwmod. 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: [GIT PULL] ARM: OMAP2+: hwmod changes for v3.13
On Fri, 11 Oct 2013, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [131011 10:08]: Basic test logs are available at: http://www.pwsan.com/omap/testlogs/prcm_fixes_v3.13/20131009094936/ The summary reports that the 4460varsomom boots are failing, but this looks incorrect - it's probably a bug in the validation scripts here. OK I'll do a test on my panda es before sending out the branches and will apply that one hwmod patch Benoit had queued on top of this. So pulling into omap-for-v3.13/hwmod. Thanks. It boots fine on 4460varsomom, if you look at the boot log: http://www.pwsan.com/omap/testlogs/prcm_fixes_v3.13/20131009094936/boot/4460varsomom/4460varsomom_log.txt Otherwise I wouldn't have sent the pull request. - 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: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
On Fri, 11 Oct 2013, Tero Kristo wrote: Oh yea, one additional note you probably have missed. Mike asked us to fall back to vendor specific bindings at around v6 or so of this set. Take a look at v8, we have dropped the use of generic bindings, we are not trying to declare those with this set. No, I didn't miss it. This set introduces vendor specific bindings only, and even these are claimed 'unstable', which should be enough to discourage people from burning those to OTP type memory. Better to just avoid merging unstable bindings in the first place. Please keep this in mind: any change that anyone makes to the DT data needs to be supportable by the kernel into the indefinite future, once it makes it into arch/arm/boot/dts or the DT binding documentation. Also, any changes need to work for other OSes, i.e., the changes should not be Linux-specific. Those have been stated goals for the Linux DT project since day one. Some folks haven't been monitoring those goals very closely and that's unfortunate. We could have avoided some pretty big messes. - 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: [GIT PULL] ARM: OMAP2+: hwmod changes for v3.13
* Paul Walmsley p...@pwsan.com [131011 15:38]: On Fri, 11 Oct 2013, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [131011 10:08]: Basic test logs are available at: http://www.pwsan.com/omap/testlogs/prcm_fixes_v3.13/20131009094936/ The summary reports that the 4460varsomom boots are failing, but this looks incorrect - it's probably a bug in the validation scripts here. OK I'll do a test on my panda es before sending out the branches and will apply that one hwmod patch Benoit had queued on top of this. So pulling into omap-for-v3.13/hwmod. Thanks. It boots fine on 4460varsomom, if you look at the boot log: http://www.pwsan.com/omap/testlogs/prcm_fixes_v3.13/20131009094936/boot/4460varsomom/4460varsomom_log.txt Otherwise I wouldn't have sent the pull request. OK thanks! Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
* Tero Kristo t-kri...@ti.com [131010 01:25]: On 10/09/2013 09:55 PM, Paul Walmsley wrote: So in my view, the right things to do here are to: 1. associate SoC DT clock data with the device node that contains the clock control registers So, either cm, prcm, and maybe control_module instead of current clocks. How much do we benefit from this? This would get rid of need to call of_iomap() for each register basically. It seems that all you need to do for that is to set up two or three clock driver instances and have the clocks registered under them. Then later on those can be children of cm, prcm and scm core drivers as needed without much of an issue. 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 1/2] Input: twl4030_keypad - add device tree support
* Sebastian Reichel s...@debian.org [131009 14:25]:
Add device tree support for twl4030 keypad driver and update the
Documentation with twl4030 keypad device tree binding information.
This patch also adds a twl4030 keypad node to the twl4030.dtsi file,
so that board files can just add the keymap.
Tested on Nokia N900.
Nice :) Just few cosmetic comments below.
+#ifdef CONFIG_OF
+static int twl4030_keypad_parse_dt(struct device *dev,
+ struct twl4030_keypad *keypad_data)
+{
I guess the way to go nowadays is to use #IS_ENABLED(CONFIG_OF) here
and later on in this patch.
@@ -331,20 +358,12 @@ static int twl4030_kp_program(struct twl4030_keypad *kp)
static int twl4030_kp_probe(struct platform_device *pdev)
{
struct twl4030_keypad_data *pdata = pdev-dev.platform_data;
- const struct matrix_keymap_data *keymap_data;
+ const struct matrix_keymap_data *keymap_data = NULL;
struct twl4030_keypad *kp;
struct input_dev *input;
u8 reg;
int error;
- if (!pdata || !pdata-rows || !pdata-cols || !pdata-keymap_data ||
- pdata-rows TWL4030_MAX_ROWS || pdata-cols TWL4030_MAX_COLS) {
- dev_err(pdev-dev, Invalid platform_data\n);
- return -EINVAL;
- }
-
- keymap_data = pdata-keymap_data;
-
kp = kzalloc(sizeof(*kp), GFP_KERNEL);
input = input_allocate_device();
if (!kp || !input) {
I assume you have tested the above so it does not break things
for legacy booting?
Other than that:
Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: N900: TWL4030 Keypad Matrix definition
* Sebastian Reichel s...@debian.org [131009 14:26]: Add Keyboard Matrix information to N900's DTS file. This patch maps the keys exactly as the original board code. This should be queued by Benoit along with other .dts changes, not via the input tree: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 6/8] ARM: dts: OMAP4: Add hwspinlock node
* Suman Anna s-a...@ti.com [131010 14:24]: Add the hwspinlock device tree node for OMAP4 family of SoCs. Suman, can you please post the .dts changes separately from the driver changes next time so driver maintainers don't accidentally pick them up. That leads to unnecessary merge conflicts with the .dts files. Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] ARM: OMAP2+: CM cleanup series
* Tero Kristo t-kri...@ti.com [131011 09:24]: If someone could verify the omap2 changes, that would be nice. Seems to boot on my n800 just fine, dmesg below. Tony [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.12.0-rc4-00050-gf44928c (tmlind@muffinssi) (gcc version 4.3.5 (Debian 4.3.5-4) ) #245 Fri Oct 11 17:03:03 PDT 2013 [0.00] CPU: ARMv6-compatible processor [4107b362] revision 2 (ARMv6TEJ), cr=00c5387d [0.00] CPU: VIPT aliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Nokia N800 [0.00] Ignoring unrecognised tag 0x414f4d50 [0.00] bootconsole [earlycon0] enabled [0.00] debug: ignoring loglevel setting. [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 32768 [0.00] free_area_init_node: node 0, pgdat c075891c, node_mem_map c0cb9000 [0.00] Normal zone: 256 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 32768 pages, LIFO batch:7 [0.00] CPU: All CPU(s) started in SVC mode. [0.00] OMAP2420 [0.00] [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk ignore_loglevel [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 116864K/131072K available (5069K kernel code, 344K rwdata, 1812K rodata, 271K init, 5489K bss, 14208K reserved, 0K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xc880 - 0xff00 ( 872 MB) [0.00] lowmem : 0xc000 - 0xc800 ( 128 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc06c06d0 (6882 kB) [0.00] .init : 0xc06c1000 - 0xc0704ddc ( 272 kB) [0.00] .data : 0xc0706000 - 0xc075c200 ( 345 kB) [0.00].bss : 0xc075c200 - 0xc0cb8808 (5490 kB) [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa0fe000 (revision 2.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] Clocking rate (Crystal/DPLL/MPU): 19.2/658/329 MHz [0.00] OMAP clockevent source: timer1 at 32768 Hz [0.00] omap2_sync32k_clocksource_init: failed to get counter_32k resource [0.00] sched_clock: 32 bits at 100 Hz, resolution 1000ns, wraps every 4294967286ms [0.00] hw-breakpoint: CPUID feature registers not supported. Assuming v6 debug is present. [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.07] Calibrating delay loop... 217.49 BogoMIPS (lpj=1087488) [0.15] pid_max: default: 32768 minimum: 301 [0.15] Security Framework initialized [0.16] Mount-cache hash table entries: 512 [0.17] CPU: Testing write buffer coherency: ok [0.18] Setting up static identity map for 0xc04d3518 - 0xc04d3588 [0.21] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 2 [0.26] pinctrl core: initialized pinctrl subsystem [0.28] regulator-dummy: no parameters [0.29] NET: Registered protocol family 16 [0.30] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.31] omap-gpmc omap-gpmc: GPMC revision 2.0 [0.34] omap_gpio omap_gpio.0: Could not get gpio dbck [0.35] gpiochip_add: registered GPIOs 0 to 31 on device: gpio [0.36] OMAP GPIO hardware version 1.8 [0.36] omap_gpio omap_gpio.1: Could not get gpio dbck [0.37] gpiochip_add: registered GPIOs 32 to 63 on device: gpio [0.38] omap_gpio omap_gpio.2: Could not get gpio dbck [0.39] gpiochip_add: registered GPIOs 64 to 95 on device: gpio [0.40] omap_gpio omap_gpio.3: Could not get gpio dbck [0.41] gpiochip_add: registered GPIOs 96 to
Re: [PATCH 00/11] ARM: OMAP2+: CM cleanup series
* Tony Lindgren t...@atomide.com [131011 17:18]: * Tero Kristo t-kri...@ti.com [131011 09:24]: If someone could verify the omap2 changes, that would be nice. Seems to boot on my n800 just fine, dmesg below. Sorry that was the log without these patches, still boots fine with the patches too though. Bootlog with your patches below, at least now you can diff them after removing the time stamps :) Regards, Tony [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.12.0-rc4-00061-gb99884a (tmlind@muffinssi) (gcc version 4.3.5 (Debian 4.3.5-4) ) #247 Fri Oct 11 17:14:37 PDT 2013 [0.00] CPU: ARMv6-compatible processor [4107b362] revision 2 (ARMv6TEJ), cr=00c5387d [0.00] CPU: VIPT aliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Nokia N800 [0.00] Ignoring unrecognised tag 0x414f4d50 [0.00] bootconsole [earlycon0] enabled [0.00] debug: ignoring loglevel setting. [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 32768 [0.00] free_area_init_node: node 0, pgdat c075891c, node_mem_map c0cb9000 [0.00] Normal zone: 256 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 32768 pages, LIFO batch:7 [0.00] CPU: All CPU(s) started in SVC mode. [0.00] OMAP2420 [0.00] [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 earlyprintk ignore_loglevel [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 116864K/131072K available (5069K kernel code, 344K rwdata, 1812K rodata, 271K init, 5489K bss, 14208K reserved, 0K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xc880 - 0xff00 ( 872 MB) [0.00] lowmem : 0xc000 - 0xc800 ( 128 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc06c0700 (6882 kB) [0.00] .init : 0xc06c1000 - 0xc0704ddc ( 272 kB) [0.00] .data : 0xc0706000 - 0xc075c200 ( 345 kB) [0.00].bss : 0xc075c200 - 0xc0cb8808 (5490 kB) [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa0fe000 (revision 2.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] Clocking rate (Crystal/DPLL/MPU): 19.2/658/329 MHz [0.00] OMAP clockevent source: timer1 at 32768 Hz [0.00] omap2_sync32k_clocksource_init: failed to get counter_32k resource [0.00] sched_clock: 32 bits at 100 Hz, resolution 1000ns, wraps every 4294967286ms [0.00] hw-breakpoint: CPUID feature registers not supported. Assuming v6 debug is present. [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.07] Calibrating delay loop... 217.49 BogoMIPS (lpj=1087488) [0.15] pid_max: default: 32768 minimum: 301 [0.15] Security Framework initialized [0.16] Mount-cache hash table entries: 512 [0.17] CPU: Testing write buffer coherency: ok [0.18] Setting up static identity map for 0xc04d3618 - 0xc04d3688 [0.21] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 2 [0.26] pinctrl core: initialized pinctrl subsystem [0.28] regulator-dummy: no parameters [0.29] NET: Registered protocol family 16 [0.30] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.31] omap-gpmc omap-gpmc: GPMC revision 2.0 [0.34] omap_gpio omap_gpio.0: Could not get gpio dbck [0.35] gpiochip_add: registered GPIOs 0 to 31 on device: gpio [0.36] OMAP GPIO hardware version 1.8 [0.36] omap_gpio omap_gpio.1: Could not get gpio dbck [0.37] gpiochip_add: registered GPIOs 32 to 63 on
Re: [PATCH V5] ARM: OMAP5/DRA7: realtime_counter: Configure CNTFRQ register
* Tony Lindgren t...@atomide.com [131010 10:23]:
* Santosh Shilimkar santosh.shilim...@ti.com [131010 06:20]:
On Thursday 10 October 2013 03:43 AM, Sricharan R wrote:
From: R Sricharan r.sricha...@ti.com
The realtime counter called master counter, produces the count
used by the private timer peripherals in the MPU_CLUSTER. The
CNTFRQ per cpu register is used to denote the frequency of the counter.
Currently the frequency value is passed from the
DT file, but this is not scalable when we have other non-DT guest
OS. This register must be set to the right value by the
secure rom code. Setting this register helps in propagating the right
frequency value across OSes.
More discussions and the reason for adding this in a non-DT
way can be seen from below.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93832.html
So configuring this secure register for all the cpus here.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Tony Lindgren t...@atomide.com
Tested-by: Nishanth Menon n...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V5] Removed the use of extern variable in omap-smp.c
as per suggestion from Santosh Shilimkar santosh.shilim...@ti.com
Thanks for the updates Sricharan. Looks fine now.
Tony, Can you apply this version if you are fine with it.
Yes thanks looks good to me now. Applying into omap-for-v3.13/soc.
Grr, had to apply the following fix on top of this for some configs.
Tony
8 ---
From: Tony Lindgren t...@atomide.com
Date: Fri, 11 Oct 2013 17:28:04 -0700
Subject: [PATCH] ARM: OMAP2+: Fix build error for realtime counter init if not
enabled
Otherwise we can get an error with some configs:
arch/arm/mach-omap2/timer.c:73: undefined reference to `omap_smc1'
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -66,12 +66,15 @@
static struct omap_dm_timer clkev;
static struct clock_event_device clockevent_gpt;
+
+#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
static unsigned long arch_timer_freq;
void set_cntfreq(void)
{
omap_smc1(OMAP5_DRA7_MON_SET_CNTFRQ_INDEX, arch_timer_freq);
}
+#endif
static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
{
--
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] ARM: OMAP5/DRA7: realtime_counter: Configure CNTFRQ register
On Friday 11 October 2013 08:34 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [131010 10:23]: * Santosh Shilimkar santosh.shilim...@ti.com [131010 06:20]: On Thursday 10 October 2013 03:43 AM, Sricharan R wrote: From: R Sricharan r.sricha...@ti.com The realtime counter called master counter, produces the count used by the private timer peripherals in the MPU_CLUSTER. The CNTFRQ per cpu register is used to denote the frequency of the counter. Currently the frequency value is passed from the DT file, but this is not scalable when we have other non-DT guest OS. This register must be set to the right value by the secure rom code. Setting this register helps in propagating the right frequency value across OSes. More discussions and the reason for adding this in a non-DT way can be seen from below. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93832.html So configuring this secure register for all the cpus here. Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Nishanth Menon n...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Marc Zyngier marc.zyng...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Tony Lindgren t...@atomide.com Tested-by: Nishanth Menon n...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com --- [V5] Removed the use of extern variable in omap-smp.c as per suggestion from Santosh Shilimkar santosh.shilim...@ti.com Thanks for the updates Sricharan. Looks fine now. Tony, Can you apply this version if you are fine with it. Yes thanks looks good to me now. Applying into omap-for-v3.13/soc. Grr, had to apply the following fix on top of this for some configs. Looks like Sricharan missed some builds. Sorry for the trouble Tony. 8 --- From: Tony Lindgren t...@atomide.com Date: Fri, 11 Oct 2013 17:28:04 -0700 Subject: [PATCH] ARM: OMAP2+: Fix build error for realtime counter init if not enabled Otherwise we can get an error with some configs: arch/arm/mach-omap2/timer.c:73: undefined reference to `omap_smc1' Signed-off-by: Tony Lindgren t...@atomide.com Looks fine to me. Thanks Regards, Santosh -- 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
