* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mitch Bradley @ 2012-10-23 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023172035.GB32167@arwen.pp.htv.fi>
Perhaps I misunderstood what you were suggesting. I thought that, when
you said "explicitly manage all their resources", you meant that the
driver should know the platform-specific details about clocks and power
domains. That is one possible interpretation of the word "explicit".
Now I see that you meant that the driver should explicitly call
abstracted functions.
On 10/23/2012 7:20 AM, Felipe Balbi wrote:
> HI,
>
> On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote:
>> On 10/23/2012 12:03 AM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> I much prefer having drivers explicitly manage all their resources,
>>> which would mean that pinctrl calls need to be done on probe() and, if
>>> necessary, during suspend()/resume().
>>
>>
>> Per-driver resource management is certainly convenient when you are
>> dealing with a single system, but it becomes difficult to maintain for
>> drivers that are shared among many platforms.
>
> why ? look at drivers/usb/dwc3/, we're using that on OMAP, exynos, PCIe
> and a couple of different FPGA implementations inside TI. Not to mention
> what other licensees of that IP core might have internally.
>
> So far no problesm with resources at all.
>
> We have frameworks exactly to hide the differences.
>
>> The industry trend for many years has been consolidation around a single
>> programming model per class of device. For example, SDHCI, EHCI, ATA.
>> This trend will only accelerate, as the cost of developing controller IP
>> and associated drivers increases. Such drivers need to be as
>> platform-agnostic as possible.
>
> that's why we have pinctrl framework to abstract the details about pin
> muxing.
>
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Felipe Balbi @ 2012-10-23 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5086D91A.5080109@firmworks.com>
Hi,
(please don't top-post)
On Tue, Oct 23, 2012 at 07:51:22AM -1000, Mitch Bradley wrote:
> Perhaps I misunderstood what you were suggesting. I thought that, when
> you said "explicitly manage all their resources", you meant that the
> driver should know the platform-specific details about clocks and power
> domains. That is one possible interpretation of the word "explicit".
we had two suggestions in the thread:
1) handle it in driver source code (explict)
2) handle at bus notifiers level (hidden)
archives would've helped you clear up that confusion ;-)
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/87fc4f04/attachment.sig>
^ permalink raw reply
* [PATCH] i2c: omap: re-factor omap_i2c_init function
From: Shubhrajyoti Datta @ 2012-10-23 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023171840.GA32167@arwen.pp.htv.fi>
On Tue, Oct 23, 2012 at 10:48 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Tue, Oct 23, 2012 at 08:57:19PM +0530, Shubhrajyoti D wrote:
>> re-factor omap_i2c_init() so that we can re-use it for resume.
>> While at it also remove the bufstate variable as we write it
>> in omap_i2c_resize_fifo for every transfer.
>>
>> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
>> ---
>> Applies on Felipe's series
>> http://www.spinics.net/lists/linux-omap/msg79995.html
>>
>> Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
>> on omap3636 beagle both idle and suspend.
>>
>> Functional testing on omap4sdp.
>>
>> drivers/i2c/busses/i2c-omap.c | 68 +++++++++++++++++------------------------
>> 1 files changed, 28 insertions(+), 40 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
>> index 5e5cefb..338cee7 100644
>> --- a/drivers/i2c/busses/i2c-omap.c
>> +++ b/drivers/i2c/busses/i2c-omap.c
>> @@ -209,7 +209,6 @@ struct omap_i2c_dev {
>> u16 pscstate;
>> u16 scllstate;
>> u16 sclhstate;
>> - u16 bufstate;
>> u16 syscstate;
>> u16 westate;
>> u16 errata;
>> @@ -285,9 +284,26 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg)
>> }
>> }
>>
>> +static void __omap_i2c_init(struct omap_i2c_dev *dev)
>> +{
>> +
>> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
>> + /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
>> + omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
>> +
>> + /* SCL low and high time values */
>> + omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
>> + omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
>> + if (dev->rev >= OMAP_I2C_REV_ON_3430_3530)
>> + omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
>> + /* Take the I2C module out of reset: */
>> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
>> + omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
>> +
>> +}
>> static int omap_i2c_init(struct omap_i2c_dev *dev)
>> {
>> - u16 psc = 0, scll = 0, sclh = 0, buf = 0;
>> + u16 psc = 0, scll = 0, sclh = 0;
>> u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
>> unsigned long fclk_rate = 12000000;
>> unsigned long timeout;
>> @@ -337,11 +353,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>> * REVISIT: Some wkup sources might not be needed.
>> */
>> dev->westate = OMAP_I2C_WE_ALL;
>> - omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
>> - dev->westate);
>> }
>> }
>> - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
>>
>> if (dev->flags & OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
>> /*
>> @@ -426,28 +439,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>> sclh = fclk_rate / (dev->speed * 2) - 7 + psc;
>> }
>>
>> - /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
>> - omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
>> -
>> - /* SCL low and high time values */
>> - omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
>> - omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
>> -
>> - /* Take the I2C module out of reset: */
>> - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
>> -
>> /* Enable interrupts */
>> dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
>> OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL) |
>> ((dev->fifo_size) ? (OMAP_I2C_IE_RDR |
>> OMAP_I2C_IE_XDR) : 0);
>> - omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
>> - if (dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
>> - dev->pscstate = psc;
>> - dev->scllstate = scll;
>> - dev->sclhstate = sclh;
>> - dev->bufstate = buf;
>> - }
>> +
>> + dev->pscstate = psc;
>> + dev->scllstate = scll;
>> + dev->sclhstate = sclh;
>> +
>> + __omap_i2c_init(dev);
>> +
>> return 0;
>> }
>>
>> @@ -1136,7 +1139,7 @@ omap_i2c_probe(struct platform_device *pdev)
>> if (IS_ERR_VALUE(r))
>> goto err_free_mem;
>>
>> - dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
>> + dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
>
> trailing change. not part of $SUBJECT
my mistake will remove.
>
>> dev->errata = 0;
>>
>> @@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
>> {
>> struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
>>
>> - if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
>> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
>> - omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
>> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev->scllstate);
>> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev->sclhstate);
>> - omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev->bufstate);
>> - omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev->syscstate);
>> - omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev->westate);
>> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
>> - }
>> -
>> - /*
>> - * Don't write to this register if the IE state is 0 as it can
>> - * cause deadlock.
>> - */
>> - if (_dev->iestate)
>> - omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev->iestate);
>
> this part is not on __omap_i2c_init() so you're potentially causing a
> regression here.
iestate is set at init so cannot be zero. so the check was removed.
>
>> + if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE)
>> + __omap_i2c_init(_dev);
>
> how has this been tested ? Did you validate suspend to ram and runtime
> pm ?
yes.
beagleXm hitting off on idle and suspend path.
and omap4sdp didnt hit off just suspend to ram.
>
>> return 0;
>> }
>> --
>> 1.7.5.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> balbi
^ permalink raw reply
* [PATCH] i2c: omap: re-factor omap_i2c_init function
From: Felipe Balbi @ 2012-10-23 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM=Q2cs-+O_BFrZFX4fuBooogEZiQO2Zxbm8W40vN9hmampLCA@mail.gmail.com>
Hi,
On Tue, Oct 23, 2012 at 11:26:15PM +0530, Shubhrajyoti Datta wrote:
> >> @@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
> >> {
> >> struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
> >>
> >> - if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev->scllstate);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev->sclhstate);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev->bufstate);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev->syscstate);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev->westate);
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
> >> - }
> >> -
> >> - /*
> >> - * Don't write to this register if the IE state is 0 as it can
> >> - * cause deadlock.
> >> - */
> >> - if (_dev->iestate)
> >> - omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev->iestate);
> >
> > this part is not on __omap_i2c_init() so you're potentially causing a
> > regression here.
>
> iestate is set at init so cannot be zero. so the check was removed.
so you never read it back ? Then you need to add a note for that in
changelog, since this is a behavior change ;-)
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/5b08f585/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Alan Stern @ 2012-10-23 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5086C2B0.6070006@wwwdotorg.org>
On Tue, 23 Oct 2012, Stephen Warren wrote:
> >> So, rather than:
> >>
> >> compatible = "usb-ehci";
> >>
> >> You should always have e.g.:
> >>
> >> compatible = "nvidia,tegra20-ehci", "usb-ehci";
> >>
> >> Given that, there is then always enough information in the device tree
> >> for the driver to be able to derive the other values from the compatible
> >> value.
> >
> > Yes, I get it.
> >
> >> Whether you want to derive the information, or whether you want to
> >> explicitly represent it via properties, is a decision to make based on
> >> the trade-offs.
> >>
> >> Oh, and I note that quite a few device trees already use compatible
> >> value "usb-ehci" in their device-trees. Care needs to be taken not to
> >> usurp that value from any existing device drivers if that was to be
> >> picked as the compatible value required by this binding.
> >
> > Right. I think Tony's new binding should use compatible value
> > "usb-ehci-platform". It will essentially be a superset of "usb-ehci".
>
> I know this is bike-shedding a little bit, but...
>
> The word "platform" isn't really about describing the HW, but rather is
> derived from the Linux SW used to program that HW. DT should be purely
> about describing the HW.
>
> Perhaps "usb-ehci-generic" or "usb-ehci-simple" would be better?
Neither of those really describes the hardware either. Which name gets
used seems pretty arbitrary.
Nothing intrinsically distinguishes this class of hardware. The only
thing these devices have in common is that they can be managed by
Linux's ehci-platform driver. For that purpose, "usb-ehci-platform"
makes more sense than "usb-ehci-generic" or "usb-ehci-simple".
(It also allows the class to enlarge over time as the driver becomes
more capable -- is that a bad thing? Are DT board descriptions written
for a later kernel supposed to be unusable with an earlier kernel that
doesn't support the same features?)
In essense, we're trying to say that the HW is compatible with a
particular driver rather than with some other type of HW. Maybe DT
wasn't intended to provide this kind of information, but it seems like
a logical thing to do. Unless DT already offers some other way to
accomplish the same thing?
Alan Stern
^ permalink raw reply
* [PATCH] i2c: omap: re-factor omap_i2c_init function
From: Shubhrajyoti Datta @ 2012-10-23 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023175706.GC32517@arwen.pp.htv.fi>
On Tue, Oct 23, 2012 at 11:27 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Tue, Oct 23, 2012 at 11:26:15PM +0530, Shubhrajyoti Datta wrote:
>> >> @@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
>> >> {
>> >> struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
>> >>
>> >> - if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev->scllstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev->sclhstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev->bufstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev->syscstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev->westate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
>> >> - }
>> >> -
>> >> - /*
>> >> - * Don't write to this register if the IE state is 0 as it can
>> >> - * cause deadlock.
>> >> - */
>> >> - if (_dev->iestate)
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev->iestate);
>> >
>> > this part is not on __omap_i2c_init() so you're potentially causing a
>> > regression here.
>>
>> iestate is set at init so cannot be zero. so the check was removed.
>
> so you never read it back ? Then you need to add a note for that in
> changelog, since this is a behavior change ;-)
Indeed will do.
>
>
> --
> balbi
^ permalink raw reply
* [PATCH 1/2] ARM: dt: tegra: Add sdhci regulators
From: Marc Dietrich @ 2012-10-23 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350976740-19284-2-git-send-email-pkunapuli@nvidia.com>
Pavan,
On Tuesday 23 October 2012 12:48:59 Pavan Kunapuli wrote:
> Adding vmmc and vmmcq supplies for sdhci nodes
> in tegra dt files.
<...>
> diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
> b/arch/arm/boot/dts/tegra20-paz00.dts index 6a93d14..e161b65 100644
> --- a/arch/arm/boot/dts/tegra20-paz00.dts
> +++ b/arch/arm/boot/dts/tegra20-paz00.dts
> @@ -422,13 +422,17 @@
> status = "okay";
> cd-gpios = <&gpio 173 0>; /* gpio PV5 */
> wp-gpios = <&gpio 57 0>; /* gpio PH1 */
> - power-gpios = <&gpio 169 0>; /* gpio PV1 */
> bus-width = <4>;
> + vmmc-supply = <&vddio_sd_reg>;
> + vqmmc-supply = <&vddio_sd_reg>;
> };
>
> sdhci at c8000600 {
> status = "okay";
> bus-width = <8>;
> + vmmc-supply = <&vddio_sdmmc_reg>;
> + vqmmc-supply = <&vddio_sdmmc_reg>;
to make it better, this should be:
vmmc-supply = <&vcore_mmc_reg>; and
vqmmc-supply = <&vddio_nand_reg>;
with vcore_mmc_reg is ldo5 and vddio_nand_reg is the fixed regulator below.
By doing so, I get "sdhci-tegra sdhci-tegra.3: could not set regulator OCR
(-1)". MMC subsys wants to set ldo5 to 3.3V but it is fixed. I guess that's
harmless for now.
> };
>
> gpio-keys {
> @@ -465,6 +469,24 @@
> regulator-max-microvolt = <5000000>;
> regulator-always-on;
> };
> +
> + vddio_sd_reg: regulator at 1 {
> + compatible = "regulator-fixed";
> + reg = <1>;
> + regulator-name = "vddio_sd";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + enable-active-high;
> + gpio = <&gpio 169 0>; /* gpio PV1 */
> + };
> +
> + vddio_sdmmc_reg: regulator at 2 {
^^ vddio_nand_reg acording to schematics
> + compatible = "regulator-fixed";
> + reg = <2>;
> + regulator-name = "vddio_sdmmc";
also here
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> };
>
> sound {
^ permalink raw reply
* [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
From: Kevin Hilman @ 2012-10-23 18:09 UTC (permalink / raw)
To: linux-arm-kernel
From: Kevin Hilman <khilman@ti.com>
When debounce clocks are disabled, ensure that the banks
dbck_enable_mask is cleared also. Otherwise, context restore on
subsequent off-mode transition will restore previous value from the
shadow copies (bank->context.debounce*) leading to mismatch state
between driver state and hardware state.
This was discovered when board code was doing
gpio_request_one()
gpio_set_debounce()
gpio_free()
which was leaving the GPIO debounce settings in a confused state.
Then, enabling off mode causing bogus state to be restored, leaving
GPIO debounce enabled which then prevented the CORE powerdomain from
transitioning.
Reported-by: Paul Walmsley <paul@pwsan.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
Applies on v3.7-rc2, targetted for v3.7.
drivers/gpio/gpio-omap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..dee2856 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -187,6 +187,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank *bank)
* to detect events and generate interrupts at least on OMAP3.
*/
__raw_writel(0, bank->base + bank->regs->debounce_en);
+ bank->dbck_enable_mask = 0;
clk_disable(bank->dbck);
bank->dbck_enabled = false;
--
1.8.0
^ permalink raw reply related
* [PATCH] ARM: dts: exynos4: Enable serial controllers on Origen and SMDKV310
From: Tomasz Figa @ 2012-10-23 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01d201cdb116$59de2520$0d9a6f60$%kim@samsung.com>
On Tuesday 23 of October 2012 21:03:01 Kukjin Kim wrote:
> Tomasz Figa wrote:
> > However I think this should be considered a fix, because without it
> > serial console on Origen and SMDKV310 will be broken.
>
> Well, I couldn't find any broken due to miss this for v3.7. I think,
> there is no usage of serial controller in mainline for Origen and
> SMDKV310 now. So this should be queued for -next. If not, please let me
> know.
Personally I'm fine with this, but it sounds a bit off, since (correct me
if I am wrong) it looks like serial console is the only way to check if
the board boots.
Best regards,
Tomasz Figa
^ permalink raw reply
* OMAP baseline test results for v3.7-rc2
From: Kevin Hilman @ 2012-10-23 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r4oqc833.fsf@deeprootsystems.com>
Kevin Hilman <khilman@deeprootsystems.com> writes:
> +Igor
>
> Paul Walmsley <paul@pwsan.com> writes:
>
>> Here are some basic OMAP test results for Linux v3.7-rc2.
>> Logs and other details at:
>>
>> http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
>
> [...]
>
>> * 37xx EVM: CORE not entering dynamic off-idle
>> - Cause unknown; dynamic retention-idle seems to work; system suspend to
>> off works
>
> I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
> SPI1 was not idle when going off. A quick hack disabling the
> touchscreen showed that after that, core was hitting idle just fine.
>
> I ran out of time today debugging this, but it's definitely realted to
> the GPIO debounce setting for the touchscreen. Changing it to zero[1]
> makes CORE hit retention again in idle.
OK, found the root cause of this in the GPIO driver. Patch submitted:
http://marc.info/?l=linux-omap&m=135101577925972&w=2
however...
> Igor, I'm hoping you might know what's going on here since we already
> had some problems with this ads7846 init stuff and you're more familiar
> with this debounce init.
... board files that are setting debounce values for ads7846 will no
longer work.
Currently, omap_ads7846_init() in common-board-devices.c does this:
gpio_request_one()
gpio_set_debounce()
gpio_free()
because of a bug in the GPIO driver, the debounce settings were sticky
and lingered even after the gpio_free(). That bug has been fixed by the
above patch, which means the above gpio_set_debounce() is completely
pointless because it's followed immediately by a gpio_free().
IMO, the whole GPIO init for the ads7846 needs a rethink as it's
currently partially done by common-board-devices.c and done (again) in
the ads7846 driver. If the gpio_free() isn't done in
common-board-devices, then the ads7846 driver will currently fail to
probe/load becasue it can't request a GPIO line.
Having found and fixed the PM regression, I'll leave the ads7846 cleanup to
somone else.
Kevin
^ permalink raw reply
* [PATCH v2] ARM: EXYNOS: Add support for secondary CPU bring-up on Exynos4412
From: Tomasz Figa @ 2012-10-23 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01d101cdb115$965b0730$c3111590$%kim@samsung.com>
Hi Kgene,
On Tuesday 23 of October 2012 20:57:33 Kukjin Kim wrote:
> Tomasz Figa wrote:
> > Exynos4412 uses different information register for each core. This
> > patch adjusts the bring-up code to take that into account.
> >
> > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> > ---
> >
> > arch/arm/mach-exynos/platsmp.c | 27 +++++++++++++++++++++------
> > 1 file changed, 21 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-
> > exynos/platsmp.c
> > index 36c3984..816a27d 100644
> > --- a/arch/arm/mach-exynos/platsmp.c
> > +++ b/arch/arm/mach-exynos/platsmp.c
> > @@ -34,8 +34,19 @@
> >
> > extern void exynos4_secondary_startup(void);
> >
> > -#define CPU1_BOOT_REG (samsung_rev() == EXYNOS4210_REV_1_1
>
> ? \
>
> > - S5P_INFORM5 : S5P_VA_SYSRAM)
> > +static inline void __iomem *cpu_boot_reg_base(void)
> > +{
> > + if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_1_1)
> > + return S5P_INFORM5;
> > + return S5P_VA_SYSRAM;
> > +}
> > +
> > +static inline void __iomem *cpu_boot_reg(int cpu)
> > +{
> > + if (soc_is_exynos4412())
> > + return cpu_boot_reg_base() + 4*cpu;
> > + return cpu_boot_reg_base();
> > +}
> >
> > /*
> >
> > * control for which core is the next to come out of the secondary
> >
> > @@ -89,6 +100,7 @@ void __cpuinit platform_secondary_init(unsigned int
>
> cpu)
>
> > int __cpuinit boot_secondary(unsigned int cpu, struct task_struct
> > *idle) {
> >
> > unsigned long timeout;
> >
> > + unsigned long phys_cpu = cpu_logical_map(cpu);
> >
> > /*
> >
> > * Set synchronisation state between this boot processor
> >
> > @@ -104,7 +116,7 @@ int __cpuinit boot_secondary(unsigned int cpu,
> > struct task_struct *idle)
> >
> > * Note that "pen_release" is the hardware CPU ID, whereas
> > * "cpu" is Linux's internal ID.
> > */
> >
> > - write_pen_release(cpu_logical_map(cpu));
> > + write_pen_release(phys_cpu);
> >
> > if (!(__raw_readl(S5P_ARM_CORE1_STATUS) & S5P_CORE_LOCAL_PWR_EN)) {
> >
> > __raw_writel(S5P_CORE_LOCAL_PWR_EN,
> >
> > @@ -138,7 +150,7 @@ int __cpuinit boot_secondary(unsigned int cpu,
> > struct task_struct *idle)
> >
> > smp_rmb();
> >
> > __raw_writel(virt_to_phys(exynos4_secondary_startup),
> >
> > - CPU1_BOOT_REG);
> > +
>
> cpu_boot_reg(phys_cpu));
>
> > gic_raise_softirq(cpumask_of(cpu), 1);
> >
> > if (pen_release == -1)
> >
> > @@ -186,6 +198,8 @@ void __init smp_init_cpus(void)
> >
> > void __init platform_smp_prepare_cpus(unsigned int max_cpus)
> > {
> >
> > + int i;
> > +
> >
> > if (!soc_is_exynos5250())
> >
> > scu_enable(scu_base_addr());
> >
> > @@ -195,6 +209,7 @@ void __init platform_smp_prepare_cpus(unsigned int
> > max_cpus)
> >
> > * until it receives a soft interrupt, and then the
> > * secondary CPU branches to this address.
> > */
> >
> > - __raw_writel(virt_to_phys(exynos4_secondary_startup),
> > - CPU1_BOOT_REG);
> > + for (i = 1; i < max_cpus; ++i)
> > + __raw_writel(virt_to_phys(exynos4_secondary_startup),
> > + cpu_boot_reg(cpu_logical_map(i)));
> >
> > }
> >
> > --
> > 1.7.12
>
> Looks ok to me, applied.
>
> Thanks.
This is an old version of the patch. A new one was posted as a part of the
series adding support for firmware ops, with corrections for received
comments.
Best regards,
Tomasz Figa
^ permalink raw reply
* [PATCH 1/3] ARM: timer: fix checkpatch warnings
From: Stephen Warren @ 2012-10-23 18:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Warren <swarren@nvidia.com>
This prevents checkpatch complaining when this file is moved in a later
patch.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
arch/arm/mach-tegra/timer.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-tegra/timer.c b/arch/arm/mach-tegra/timer.c
index e5deb54..026bad4 100644
--- a/arch/arm/mach-tegra/timer.c
+++ b/arch/arm/mach-tegra/timer.c
@@ -185,8 +185,7 @@ static void __init tegra_init_timer(void)
clk = clk_get_sys("timer", NULL);
if (IS_ERR(clk)) {
- pr_warn("Unable to get timer clock."
- " Assuming 12Mhz input clock.\n");
+ pr_warn("Unable to get timer clock. Assuming 12Mhz input clock.\n");
rate = 12000000;
} else {
clk_prepare_enable(clk);
@@ -226,13 +225,13 @@ static void __init tegra_init_timer(void)
if (clocksource_mmio_init(timer_reg_base + TIMERUS_CNTR_1US,
"timer_us", 1000000, 300, 32, clocksource_mmio_readl_up)) {
- printk(KERN_ERR "Failed to register clocksource\n");
+ pr_err("Failed to register clocksource\n");
BUG();
}
ret = setup_irq(tegra_timer_irq.irq, &tegra_timer_irq);
if (ret) {
- printk(KERN_ERR "Failed to register timer IRQ: %d\n", ret);
+ pr_err("Failed to register timer IRQ: %d\n", ret);
BUG();
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] ARM: tegra: enhance timer.c to get IO address from device tree
From: Stephen Warren @ 2012-10-23 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351016892-21211-1-git-send-email-swarren@wwwdotorg.org>
From: Stephen Warren <swarren@nvidia.com>
Modify Tegra's timer code to parse the IO address from device tree,
hence removing the dependency on <mach/iomap.h>. This will allow the
driver to be moved to drivers/clocksource/.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
arch/arm/mach-tegra/timer.c | 32 ++++++++++++++++++++++++++++----
1 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-tegra/timer.c b/arch/arm/mach-tegra/timer.c
index 026bad4..e4863f3 100644
--- a/arch/arm/mach-tegra/timer.c
+++ b/arch/arm/mach-tegra/timer.c
@@ -26,6 +26,7 @@
#include <linux/clocksource.h>
#include <linux/clk.h>
#include <linux/io.h>
+#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <asm/mach/time.h>
@@ -33,8 +34,6 @@
#include <asm/sched_clock.h>
#include "board.h"
-#include "clock.h"
-#include "iomap.h"
#define RTC_SECONDS 0x08
#define RTC_SHADOW_SECONDS 0x0c
@@ -52,8 +51,8 @@
#define TIMER_PTV 0x0
#define TIMER_PCR 0x4
-static void __iomem *timer_reg_base = IO_ADDRESS(TEGRA_TMR1_BASE);
-static void __iomem *rtc_base = IO_ADDRESS(TEGRA_RTC_BASE);
+static void __iomem *timer_reg_base;
+static void __iomem *rtc_base;
static struct timespec persistent_ts;
static u64 persistent_ms, last_persistent_ms;
@@ -164,6 +163,11 @@ static const struct of_device_id timer_match[] __initconst = {
{}
};
+static const struct of_device_id rtc_match[] __initconst = {
+ { .compatible = "nvidia,tegra20-rtc" },
+ {}
+};
+
static void __init tegra_init_timer(void)
{
struct device_node *np;
@@ -177,6 +181,12 @@ static void __init tegra_init_timer(void)
BUG();
}
+ timer_reg_base = of_iomap(np, 0);
+ if (!timer_reg_base) {
+ pr_err("Can't map timer registers");
+ BUG();
+ }
+
tegra_timer_irq.irq = irq_of_parse_and_map(np, 2);
if (tegra_timer_irq.irq <= 0) {
pr_err("Failed to map timer IRQ\n");
@@ -192,6 +202,20 @@ static void __init tegra_init_timer(void)
rate = clk_get_rate(clk);
}
+ of_node_put(np);
+
+ np = of_find_matching_node(NULL, rtc_match);
+ if (!np) {
+ pr_err("Failed to find RTC DT node\n");
+ BUG();
+ }
+
+ rtc_base = of_iomap(np, 0);
+ if (!rtc_base) {
+ pr_err("Can't map RTC registers");
+ BUG();
+ }
+
/*
* rtc registers are used by read_persistent_clock, keep the rtc clock
* enabled
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] ARM: tegra: move timer.c to drivers/clocksource/
From: Stephen Warren @ 2012-10-23 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351016892-21211-1-git-send-email-swarren@wwwdotorg.org>
From: Stephen Warren <swarren@nvidia.com>
Move arch/arm/mach-tegra/timer.c to drivers/clocksource/tegra20_timer.c
so that the code is co-located with other clocksource drivers, and to
reduce the size of the mach-tegra directory.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
arch/arm/mach-tegra/Makefile | 1 -
arch/arm/mach-tegra/board-dt-tegra20.c | 3 +-
arch/arm/mach-tegra/board-dt-tegra30.c | 3 +-
arch/arm/mach-tegra/board.h | 1 -
drivers/clocksource/Makefile | 1 +
.../timer.c => drivers/clocksource/tegra20_timer.c | 7 +----
include/linux/tegra20_timer.h | 24 ++++++++++++++++++++
7 files changed, 31 insertions(+), 9 deletions(-)
rename arch/arm/mach-tegra/timer.c => drivers/clocksource/tegra20_timer.c (98%)
create mode 100644 include/linux/tegra20_timer.h
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index 9aa653b..4a59038 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -2,7 +2,6 @@ obj-y += common.o
obj-y += io.o
obj-y += irq.o
obj-y += clock.o
-obj-y += timer.o
obj-y += fuse.o
obj-y += pmc.o
obj-y += flowctrl.o
diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c b/arch/arm/mach-tegra/board-dt-tegra20.c
index 0419056..b66f7e7 100644
--- a/arch/arm/mach-tegra/board-dt-tegra20.c
+++ b/arch/arm/mach-tegra/board-dt-tegra20.c
@@ -33,6 +33,7 @@
#include <linux/i2c.h>
#include <linux/i2c-tegra.h>
#include <linux/usb/tegra_usb_phy.h>
+#include <linux/tegra20_timer.h>
#include <asm/hardware/gic.h>
#include <asm/mach-types.h>
@@ -184,7 +185,7 @@ DT_MACHINE_START(TEGRA_DT, "nVidia Tegra20 (Flattened Device Tree)")
.init_early = tegra20_init_early,
.init_irq = tegra_dt_init_irq,
.handle_irq = gic_handle_irq,
- .timer = &tegra_sys_timer,
+ .timer = &tegra20_sys_timer,
.init_machine = tegra_dt_init,
.init_late = tegra_dt_init_late,
.restart = tegra_assert_system_reset,
diff --git a/arch/arm/mach-tegra/board-dt-tegra30.c b/arch/arm/mach-tegra/board-dt-tegra30.c
index 7368ebd..a47d19e 100644
--- a/arch/arm/mach-tegra/board-dt-tegra30.c
+++ b/arch/arm/mach-tegra/board-dt-tegra30.c
@@ -29,6 +29,7 @@
#include <linux/of_fdt.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
+#include <linux/tegra20_timer.h>
#include <asm/mach/arch.h>
#include <asm/hardware/gic.h>
@@ -92,7 +93,7 @@ DT_MACHINE_START(TEGRA30_DT, "NVIDIA Tegra30 (Flattened Device Tree)")
.init_early = tegra30_init_early,
.init_irq = tegra_dt_init_irq,
.handle_irq = gic_handle_irq,
- .timer = &tegra_sys_timer,
+ .timer = &tegra20_sys_timer,
.init_machine = tegra30_dt_init,
.init_late = tegra_init_late,
.restart = tegra_assert_system_reset,
diff --git a/arch/arm/mach-tegra/board.h b/arch/arm/mach-tegra/board.h
index 91fbe73..da8f5a3 100644
--- a/arch/arm/mach-tegra/board.h
+++ b/arch/arm/mach-tegra/board.h
@@ -55,5 +55,4 @@ static inline int harmony_pcie_init(void) { return 0; }
void __init tegra_paz00_wifikill_init(void);
-extern struct sys_timer tegra_sys_timer;
#endif
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 603be36..a09c598 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_DW_APB_TIMER_OF) += dw_apb_timer_of.o
obj-$(CONFIG_CLKSRC_DBX500_PRCMU) += clksrc-dbx500-prcmu.o
obj-$(CONFIG_ARMADA_370_XP_TIMER) += time-armada-370-xp.o
obj-$(CONFIG_ARCH_BCM2835) += bcm2835_timer.o
+obj-$(CONFIG_ARCH_TEGRA) += tegra20_timer.o
obj-$(CONFIG_CLKSRC_ARM_GENERIC) += arm_generic.o
diff --git a/arch/arm/mach-tegra/timer.c b/drivers/clocksource/tegra20_timer.c
similarity index 98%
rename from arch/arm/mach-tegra/timer.c
rename to drivers/clocksource/tegra20_timer.c
index e4863f3..996ceb8 100644
--- a/arch/arm/mach-tegra/timer.c
+++ b/drivers/clocksource/tegra20_timer.c
@@ -1,6 +1,4 @@
/*
- * arch/arch/mach-tegra/timer.c
- *
* Copyright (C) 2010 Google, Inc.
*
* Author:
@@ -17,6 +15,7 @@
*
*/
+#include <linux/tegra20_timer.h>
#include <linux/init.h>
#include <linux/err.h>
#include <linux/time.h>
@@ -33,8 +32,6 @@
#include <asm/smp_twd.h>
#include <asm/sched_clock.h>
-#include "board.h"
-
#define RTC_SECONDS 0x08
#define RTC_SHADOW_SECONDS 0x0c
#define RTC_MILLISECONDS 0x10
@@ -273,7 +270,7 @@ static void __init tegra_init_timer(void)
register_persistent_clock(NULL, tegra_read_persistent_clock);
}
-struct sys_timer tegra_sys_timer = {
+struct sys_timer tegra20_sys_timer = {
.init = tegra_init_timer,
};
diff --git a/include/linux/tegra20_timer.h b/include/linux/tegra20_timer.h
new file mode 100644
index 0000000..aa9b9c4
--- /dev/null
+++ b/include/linux/tegra20_timer.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __TEGRA20_TIMER_H
+#define __TEGRA20_TIMER_H
+
+#include <asm/mach/time.h>
+
+extern struct sys_timer tegra20_sys_timer;
+
+#endif
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/4] ARM: EXYNOS: Kconfig: Rename CPU_EXYNOS4210 to SOC_EXYNOS4210
From: Tomasz Figa @ 2012-10-23 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01d301cdb119$6849acd0$38dd0670$%kim@samsung.com>
Hi Kgene,
Thanks for your comments.
On Tuesday 23 of October 2012 21:24:54 Kukjin Kim wrote:
> Tomasz Figa wrote:
> > This patch renames CONFIG_CPU_EXYNOS4210 to CONFIG_SOC_EXYNOS4210 to
> > match the convention used by rest of Exynos SoCs and correctly
> > represent the reality (Exynos4210 is a SoC, not a CPU).
> >
> > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Zhang Rui <rui.zhang@intel.com>
>
> > ---
> >
> > arch/arm/mach-exynos/Kconfig | 14 +++++++-------
> > arch/arm/mach-exynos/Makefile | 2 +-
> > arch/arm/mach-exynos/common.h | 2 +-
> > arch/arm/plat-samsung/include/plat/cpu.h | 2 +-
> > drivers/cpufreq/Kconfig.arm | 2 +-
> > drivers/devfreq/Kconfig | 2 +-
> > drivers/mmc/host/sdhci-s3c.c | 2 +-
> > drivers/tty/serial/samsung.c | 2 +-
> > 8 files changed, 14 insertions(+), 14 deletions(-)
> >
[snip]
> > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> > index f6b0a6e2..8545069 100644
> > --- a/drivers/devfreq/Kconfig
> > +++ b/drivers/devfreq/Kconfig
> > @@ -67,7 +67,7 @@ comment "DEVFREQ Drivers"
> >
> > config ARM_EXYNOS4_BUS_DEVFREQ
> >
> > bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
> >
> > - depends on CPU_EXYNOS4210 || CPU_EXYNOS4212 || CPU_EXYNOS4412
> > + depends on SOC_EXYNOS4210 || CPU_EXYNOS4212 || CPU_EXYNOS4412
>
> (+ MyungJoo Ham)
>
> MyungJoo, should be fixed separately with this.
>
> 8<--------------------------------------
>
> From: Kukjin Kim <kgene.kim@samsung.com>
> Subject: PM / devfreq: fix the dependency for EXYNOS4212 and EXYNOS4412
>
> The CPU_EXYNOS4212 and CPU_EXYNOS4412 should be fixed.
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index f6b0a6e2..e73cede 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -67,7 +67,7 @@ comment "DEVFREQ Drivers"
>
> config ARM_EXYNOS4_BUS_DEVFREQ
> bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
> - depends on CPU_EXYNOS4210 || CPU_EXYNOS4212 || CPU_EXYNOS4412
> + depends on CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412
> select ARCH_HAS_OPP
> select DEVFREQ_GOV_SIMPLE_ONDEMAND
> help
> 8<--------------------------------------
Indeed, in result this would make my patch:
- depends on CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412
+ depends on SOC_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412
(with your patch as a dependency)
> > select ARCH_HAS_OPP
> > select DEVFREQ_GOV_SIMPLE_ONDEMAND
> > help
> >
> > diff --git a/drivers/mmc/host/sdhci-s3c.c
> > b/drivers/mmc/host/sdhci-s3c.c index a50c205..b090415 100644
> > --- a/drivers/mmc/host/sdhci-s3c.c
> > +++ b/drivers/mmc/host/sdhci-s3c.c
> > @@ -716,7 +716,7 @@ static const struct dev_pm_ops sdhci_s3c_pmops = {
> >
> > #define SDHCI_S3C_PMOPS NULL
> > #endif
> >
> > -#if defined(CONFIG_CPU_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212)
> > +#if defined(CONFIG_SOC_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212)
> >
> > static struct sdhci_s3c_drv_data exynos4_sdhci_drv_data = {
> >
> > .sdhci_quirks = SDHCI_QUIRK_NONSTANDARD_CLOCK,
> >
> > };
> >
> > diff --git a/drivers/tty/serial/samsung.c
> > b/drivers/tty/serial/samsung.c index 02d07bf..175ba6e 100644
> > --- a/drivers/tty/serial/samsung.c
> > +++ b/drivers/tty/serial/samsung.c
> > @@ -1594,7 +1594,7 @@ static struct s3c24xx_serial_drv_data
> > s5pv210_serial_drv_data = {
> >
> > #define S5PV210_SERIAL_DRV_DATA (kernel_ulong_t)NULL
> > #endif
> >
> > -#if defined(CONFIG_CPU_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212)
> > || \ +#if defined(CONFIG_SOC_EXYNOS4210) ||
> > defined(CONFIG_SOC_EXYNOS4212) || \>
> > defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250)
> >
> > static struct s3c24xx_serial_drv_data exynos4210_serial_drv_data = {
> >
> > .info = &(struct s3c24xx_uart_info) {
> >
> > --
> > 1.7.12
>
> Tomasz, looks ok to me but I think, accordingly, following should be
> updated together?
>
> 8<--------------------------------
>
> diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
> index a006f0d..3a665ff 100644
> --- a/drivers/gpio/gpio-samsung.c
> +++ b/drivers/gpio/gpio-samsung.c
> @@ -2790,7 +2790,7 @@ static __init void
> exynos_gpiolib_attach_ofnode(struct samsung_gpio_chip *chip,
>
> static __init void exynos4_gpiolib_init(void)
> {
> -#ifdef CONFIG_CPU_EXYNOS4210
> +#ifdef CONFIG_SOC_EXYNOS4210
> struct samsung_gpio_chip *chip;
> int i, nr_chips;
> void __iomem *gpio_base1, *gpio_base2, *gpio_base3;
> @@ -2887,7 +2887,7 @@ static __init void exynos4_gpiolib_init(void)
> samsung_gpiolib_add_4bit_chips(exynos4_gpios_3,
> nr_chips, gpio_base3);
>
> -#if defined(CONFIG_CPU_EXYNOS4210) && defined(CONFIG_S5P_GPIO_INT)
> +#if defined(CONFIG_SOC_EXYNOS4210) && defined(CONFIG_S5P_GPIO_INT)
> s5p_register_gpioint_bank(IRQ_GPIO_XA, 0, IRQ_GPIO1_NR_GROUPS);
> s5p_register_gpioint_bank(IRQ_GPIO_XB, IRQ_GPIO1_NR_GROUPS,
> IRQ_GPIO2_NR_GROUPS);
> #endif
> @@ -2900,7 +2900,7 @@ err_ioremap2:
> iounmap(gpio_base1);
> err_ioremap1:
> return;
> -#endif /* CONFIG_CPU_EXYNOS4210 */
> +#endif /* CONFIG_SOC_EXYNOS4210 */
> }
>
> static __init void exynos5_gpiolib_init(void)
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> index fd03e85..8be9282 100644
> --- a/drivers/thermal/exynos_thermal.c
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -728,7 +728,7 @@ static struct thermal_sensor_conf exynos_sensor_conf
> = { .read_temperature = (int (*)(void *))exynos_tmu_read,
> };
>
> -#if defined(CONFIG_CPU_EXYNOS4210)
> +#if defined(CONFIG_SOC_EXYNOS4210)
> static struct exynos_tmu_platform_data const
> exynos4210_default_tmu_data = {
> .threshold = 80,
> .trigger_levels[0] = 5,
> 8<--------------------------------
Yes, I must have missed them somehow, will include these missing changes
in next version.
Best regards,
Tomasz Figa
^ permalink raw reply
* Which kirkwood does your DT board use?
From: Andrew Lunn @ 2012-10-23 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5085BA54.6050006@baker-net.org.uk>
On Mon, Oct 22, 2012 at 10:27:48PM +0100, Adam Baker wrote:
> On 20/10/12 12:38, Andrew Lunn wrote:
> >Hi Folks
> >
> >All of you in the To: have contributed a DT based Kirkwood board port.
> >Nearly all the DT files we have declare the CPU to be
> >marvell,kirkwood-88f6281. For adding DT based pinctrl, to replace the
> >mpp code, we need to know the exact kirkwood being used. It should be
> >one of MV88F6180, MV88F6190, MV88F6192, MV88F6281 or MV88F6282.
> >
> >You can see what your hardware has a boot time:
> >
> >Kirkwood: MV88F6282-Rev-A0, TCLK=200000000.
> >
> >Please could you check your hardware and let me know what the correct
> >CPU is. I can then fix the .dts files and prepare a first attempt at
> >converting boards to pinctrl.
> >
>
> Hi,
>
> I've not seen a reply from Arnaud yet so I'll offer
>
> Iomega Iconnect
> Kirkwood: MV88F6281-A0, TCLK=200000000.
Hi Adam
Thanks. Arnaud replied p-t-p.
I'm was missing just one reply, but with a bit of googling, i found a
boot log online, so could fill the gap.
kirkwood-dns320.dts MV88F6281
kirkwood-dns325.dts MV88F6281
kirkwood-dockstar.dts MV88F6281
kirkwood-dreamplug.dts MV88F6281
kirkwood-goflexnet.dts MV88F6281
kirkwood-ib62x0.dts MV88F6281
kirkwood-iconnect.dts MV88F6281
kirkwood-iomega_ix2_200.dts MV88F6281
kirkwood-lschlv2.dts MV88F6281
kirkwood-lsxhl.dts MV88F6281
kirkwood-ts219-6281.dts MV88F6281
kirkwood-ts219-6282.dts MV88F6282
Not what i was expecting, nearly every one being 6281!
But it does mean there are no DT files to correct :-)
Thanks for your answers everybody.
Andrew
^ permalink raw reply
* [PATCH 1/2] ARM: dt: tegra: Add sdhci regulators
From: Stephen Warren @ 2012-10-23 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4346406.Jy2o1pWcOR@ax5200p>
On 10/23/2012 12:07 PM, Marc Dietrich wrote:
> Pavan,
>
> On Tuesday 23 October 2012 12:48:59 Pavan Kunapuli wrote:
>> Adding vmmc and vmmcq supplies for sdhci nodes
>> in tegra dt files.
>
> <...>
>
>> diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
>> b/arch/arm/boot/dts/tegra20-paz00.dts index 6a93d14..e161b65 100644
>> --- a/arch/arm/boot/dts/tegra20-paz00.dts
>> +++ b/arch/arm/boot/dts/tegra20-paz00.dts
>> @@ -422,13 +422,17 @@
>> status = "okay";
>> cd-gpios = <&gpio 173 0>; /* gpio PV5 */
>> wp-gpios = <&gpio 57 0>; /* gpio PH1 */
>> - power-gpios = <&gpio 169 0>; /* gpio PV1 */
>> bus-width = <4>;
>> + vmmc-supply = <&vddio_sd_reg>;
>> + vqmmc-supply = <&vddio_sd_reg>;
>> };
>>
>> sdhci at c8000600 {
>> status = "okay";
>> bus-width = <8>;
>> + vmmc-supply = <&vddio_sdmmc_reg>;
>> + vqmmc-supply = <&vddio_sdmmc_reg>;
>
> to make it better, this should be:
>
> vmmc-supply = <&vcore_mmc_reg>; and
> vqmmc-supply = <&vddio_nand_reg>;
>
> with vcore_mmc_reg is ldo5 and vddio_nand_reg is the fixed regulator below.
I think for the eMMC (not SD card), the core supply is actually +3vs_s3,
and hence fixed; it looks like LDO5 used to be used, but they changed
it. See the note for the VCC connections on the eMMC chip.
> By doing so, I get "sdhci-tegra sdhci-tegra.3: could not set regulator OCR
> (-1)". MMC subsys wants to set ldo5 to 3.3V but it is fixed. I guess that's
> harmless for now.
What I mention above might end up fixing that?
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Stephen Warren @ 2012-10-23 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1210231340340.1635-100000@iolanthe.rowland.org>
On 10/23/2012 11:59 AM, Alan Stern wrote:
> On Tue, 23 Oct 2012, Stephen Warren wrote:
>
>>>> So, rather than:
>>>>
>>>> compatible = "usb-ehci";
>>>>
>>>> You should always have e.g.:
>>>>
>>>> compatible = "nvidia,tegra20-ehci", "usb-ehci";
>>>>
>>>> Given that, there is then always enough information in the device tree
>>>> for the driver to be able to derive the other values from the compatible
>>>> value.
>>>
>>> Yes, I get it.
>>>
>>>> Whether you want to derive the information, or whether you want to
>>>> explicitly represent it via properties, is a decision to make based on
>>>> the trade-offs.
>>>>
>>>> Oh, and I note that quite a few device trees already use compatible
>>>> value "usb-ehci" in their device-trees. Care needs to be taken not to
>>>> usurp that value from any existing device drivers if that was to be
>>>> picked as the compatible value required by this binding.
>>>
>>> Right. I think Tony's new binding should use compatible value
>>> "usb-ehci-platform". It will essentially be a superset of "usb-ehci".
>>
>> I know this is bike-shedding a little bit, but...
>>
>> The word "platform" isn't really about describing the HW, but rather is
>> derived from the Linux SW used to program that HW. DT should be purely
>> about describing the HW.
>>
>> Perhaps "usb-ehci-generic" or "usb-ehci-simple" would be better?
>
> Neither of those really describes the hardware either. Which name gets
> used seems pretty arbitrary.
>
> Nothing intrinsically distinguishes this class of hardware. The only
> thing these devices have in common is that they can be managed by
> Linux's ehci-platform driver.
I don't agree. They're all EHCI USB controllers (or all EHCI USB
controllers that don't require custom drivers due to quirks), which is a
much more general statement than anything related to which driver Linux
uses for them.
> For that purpose, "usb-ehci-platform"
> makes more sense than "usb-ehci-generic" or "usb-ehci-simple".
>
> (It also allows the class to enlarge over time as the driver becomes
> more capable -- is that a bad thing? Are DT board descriptions written
> for a later kernel supposed to be unusable with an earlier kernel that
> doesn't support the same features?)
>
> In essense, we're trying to say that the HW is compatible with a
> particular driver rather than with some other type of HW.
Using a compatible value in order to pick a specific driver in Linux is
explicitly against the device tree design principles; DT is supposed to
represent just the hardware.
> Maybe DT
> wasn't intended to provide this kind of information, but it seems like
> a logical thing to do. Unless DT already offers some other way to
> accomplish the same thing?
The typical way is for the Linux driver to declare that is supports a
variety of different HW models.
Admittedly this is annoying when there are many HW models that otherwise
wouldn't need any driver changes, hence the desire to (additionally)
include some generic value in the compatible field, but again, what that
generic value is should be driven by the HW itself, not the SW that's
using it.
^ permalink raw reply
* [RFC] Energy/power monitoring within the kernel
From: Andy Green @ 2012-10-23 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351013449.9070.5.camel@hornet>
On 10/23/12 19:30, the mail apparently from Pawel Moll included:
> Greetings All,
>
> More and more of people are getting interested in the subject of power
> (energy) consumption monitoring. We have some external tools like
> "battery simulators", energy probes etc., but some targets can measure
> their power usage on their own.
>
> Traditionally such data should be exposed to the user via hwmon sysfs
> interface, and that's exactly what I did for "my" platform - I have
> a /sys/class/hwmon/hwmon*/device/energy*_input and this was good
> enough to draw pretty graphs in userspace. Everyone was happy...
>
> Now I am getting new requests to do more with this data. In particular
> I'm asked how to add such information to ftrace/perf output. The second
> most frequent request is about providing it to a "energy aware"
> cpufreq governor.
>
> I've came up with three (non-mutually exclusive) options. I will
> appreciate any other ideas and comments (including "it makes not sense
> whatsoever" ones, with justification). Of course I am more than willing
> to spend time on prototyping anything that seems reasonable and propose
> patches.
>
>
>
> === Option 1: Trace event ===
>
> This seems to be the "cheapest" option. Simply defining a trace event
> that can be generated by a hwmon (or any other) driver makes the
> interesting data immediately available to any ftrace/perf user. Of
> course it doesn't really help with the cpufreq case, but seems to be
> a good place to start with.
>
> The question is how to define it... I've came up with two prototypes:
>
> = Generic hwmon trace event =
>
> This one allows any driver to generate a trace event whenever any
> "hwmon attribute" (measured value) gets updated. The rate at which the
> updates happen can be controlled by already existing "update_interval"
> attribute.
>
> 8<-------------------------------------------
> TRACE_EVENT(hwmon_attr_update,
> TP_PROTO(struct device *dev, struct attribute *attr, long long input),
> TP_ARGS(dev, attr, input),
>
> TP_STRUCT__entry(
> __string( dev, dev_name(dev))
> __string( attr, attr->name)
> __field( long long, input)
> ),
>
> TP_fast_assign(
> __assign_str(dev, dev_name(dev));
> __assign_str(attr, attr->name);
> __entry->input = input;
> ),
>
> TP_printk("%s %s %lld", __get_str(dev), __get_str(attr), __entry->input)
> );
> 8<-------------------------------------------
>
> It generates such ftrace message:
>
> <...>212.673126: hwmon_attr_update: hwmon4 temp1_input 34361
>
> One issue with this is that some external knowledge is required to
> relate a number to a processor core. Or maybe it's not an issue at all
> because it should be left for the user(space)?
>
> = CPU power/energy/temperature trace event =
>
> This one is designed to emphasize the relation between the measured
> value (whether it is energy, temperature or any other physical
> phenomena, really) and CPUs, so it is quite specific (too specific?)
>
> 8<-------------------------------------------
> TRACE_EVENT(cpus_environment,
> TP_PROTO(const struct cpumask *cpus, long long value, char unit),
> TP_ARGS(cpus, value, unit),
>
> TP_STRUCT__entry(
> __array( unsigned char, cpus, sizeof(struct cpumask))
> __field( long long, value)
> __field( char, unit)
> ),
>
> TP_fast_assign(
> memcpy(__entry->cpus, cpus, sizeof(struct cpumask));
> __entry->value = value;
> __entry->unit = unit;
> ),
>
> TP_printk("cpus %s %lld[%c]",
> __print_cpumask((struct cpumask *)__entry->cpus),
> __entry->value, __entry->unit)
> );
> 8<-------------------------------------------
>
> And the equivalent ftrace message is:
>
> <...>127.063107: cpus_environment: cpus 0,1,2,3 34361[C]
>
> It's a cpumask, not just single cpu id, because the sensor may measure
> the value per set of CPUs, eg. a temperature of the whole silicon die
> (so all the cores) or an energy consumed by a subset of cores (this
> is my particular use case - two meters monitor a cluster of two
> processors and a cluster of three processors, all working as a SMP
> system).
>
> Of course the cpus __array could be actually a special __cpumask field
> type (I've just hacked the __print_cpumask so far). And I've just
> realised that the unit field should actually be a string to allow unit
> prefixes to be specified (the above should obviously be "34361[mC]"
> not "[C]"). Also - excuse the "cpus_environment" name - this was the
> best I was able to come up with at the time and I'm eager to accept
> any alternative suggestions :-)
A thought on that... from an SoC perspective there are other interesting
power rails than go to just the CPU core. For example DDR power and
rails involved with other IP units on the SoC such as 3D graphics unit.
So tying one number to specifically a CPU core does not sound like
it's enough.
> === Option 2: hwmon perf PMU ===
>
> Although the trace event makes it possible to obtain interesting
> information using perf, the user wouldn't be able to treat the
> energy meter as a normal data source. In particular there would
> be no way of creating a group of events consisting eg. of a
> "normal" leader (eg. cache miss event) triggering energy meter
> read. The only way to get this done is to implement a perf PMU
> backend providing "environmental data" to the user.
In terms of like perf top don't think it'll be possible to know when to
sample the acquisition hardware to tie the result to a particular line
of code, even if it had the bandwidth to do that. Power readings are
likely to lag activities on the cpu somewhat, considering sub-ns core
clocks, especially if it's actually measuring the input side of a regulator.
> = High-level hwmon API and PMU =
>
> Current hwmon subsystem does not provide any abstraction for the
> measured values and requires particular drivers to create specified
> sysfs attributes than used by userspace libsensors. This makes
> the framework ultimately flexible and ultimately hard to access
> from within the kernel...
>
> What could be done here is some (simple) API to register the
> measured values with the hwmon core which would result in creating
> equivalent sysfs attributes automagically, but also allow a
> in-kernel API for values enumeration and access. That way the core
> could also register a "hwmon PMU" with the perf framework providing
> data from all "compliant" drivers.
>
> = A driver-specific PMU =
>
> Of course a particular driver could register its own perf PMU on its
> own. It's certainly an option, just very suboptimal in my opinion.
> Or maybe not? Maybe the task is so specialized that it makes sense?
>
>
>
> === Option 3: CPU power(energy) monitoring framework ===
>
> And last but not least, maybe the problem deserves some dedicated
> API? Something that would take providers and feed their data into
> interested parties, in particular a perf PMU implementation and
> cpufreq governors?
>
> Maybe it could be an extension to the thermal framework? It already
> gives some meaning to a physical phenomena. Adding other, related ones
> like energy, and relating it to cpu cores could make some sense.
If you turn the problem upside down to solve the representation question
first, maybe there's a way forward defining the "power tree" in terms of
regulators, and then adding something in struct regulator that spams
readers with timestamped results if the regulator has a power monitoring
capability.
Then you can map the regulators in the power tree to real devices by the
names or the supply stuff. Just a thought.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org ? Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
^ permalink raw reply
* [PATCH 2/4] ARM: EXYNOS: Kconfig: Sort out dependencies between options
From: Tomasz Figa @ 2012-10-23 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01d401cdb11a$e4bcfff0$ae36ffd0$%kim@samsung.com>
On Tuesday 23 of October 2012 21:35:32 Kukjin Kim wrote:
> Tomasz Figa wrote:
> > This patch modifies the dependencies between Exynos-related Kconfig
> > options to represent the real dependencies between code units more
> > closely.
> >
> > Originally it was possible to enable ARCH_EXYNOS{4,5} without any
> > SOC_EXYNOS_{4,5}.* enabled, which could end with compilation or link
> > errors. Now ARCH_EXYNOS{4,5} is only selected when there is a
> > SOC_EXYNOS_{4,5}.* enabled, which requires it.
> >
> > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> > ---
> >
> > arch/arm/mach-exynos/Kconfig | 15 ++++++---------
> > drivers/devfreq/Kconfig | 2 +-
> > drivers/mmc/host/sdhci-s3c.c | 2 +-
> > drivers/tty/serial/samsung.c | 3 +--
> > 4 files changed, 9 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/Kconfig
> > b/arch/arm/mach-exynos/Kconfig index 05dcd07..9f91892 100644
> > --- a/arch/arm/mach-exynos/Kconfig
> > +++ b/arch/arm/mach-exynos/Kconfig
> > @@ -12,15 +12,14 @@ if ARCH_EXYNOS
> >
> > menu "SAMSUNG EXYNOS SoCs Support"
> >
> > config ARCH_EXYNOS4
> >
> > - bool "SAMSUNG EXYNOS4"
> > - default y
> > + def_bool n
> >
> > select HAVE_SMP
> > select MIGHT_HAVE_CACHE_L2X0
> > help
> >
> > Samsung EXYNOS4 SoCs based systems
> >
> > config ARCH_EXYNOS5
> >
> > - bool "SAMSUNG EXYNOS5"
> > + def_bool n
> >
> > select HAVE_SMP
> > help
> >
> > Samsung EXYNOS5 (Cortex-A15) SoC based systems
> >
> > @@ -30,7 +29,7 @@ comment "EXYNOS SoCs"
> >
> > config SOC_EXYNOS4210
> >
> > bool "SAMSUNG EXYNOS4210"
> > default y
> >
> > - depends on ARCH_EXYNOS4
> > + select ARCH_EXYNOS4
> >
> > select SAMSUNG_DMADEV
> > select ARM_CPU_SUSPEND if PM
> > select S5P_PM if PM
> >
> > @@ -42,7 +41,7 @@ config SOC_EXYNOS4210
> >
> > config SOC_EXYNOS4212
> >
> > bool "SAMSUNG EXYNOS4212"
> > default y
> >
> > - depends on ARCH_EXYNOS4
> > + select ARCH_EXYNOS4
> >
> > select SAMSUNG_DMADEV
> > select S5P_PM if PM
> > select S5P_SLEEP if PM
> >
> > @@ -51,6 +50,7 @@ config SOC_EXYNOS4212
> >
> > config SOC_EXYNOS4412
> >
> > bool "SAMSUNG EXYNOS4412"
> >
> > + select ARCH_EXYNOS4
> >
> > default y
> > depends on ARCH_EXYNOS4
> > select SAMSUNG_DMADEV
> >
> > @@ -60,7 +60,7 @@ config SOC_EXYNOS4412
> >
> > config SOC_EXYNOS5250
> >
> > bool "SAMSUNG EXYNOS5250"
> > default y
> >
> > - depends on ARCH_EXYNOS5
> > + select ARCH_EXYNOS5
> >
> > select SAMSUNG_DMADEV
> > select S5P_PM if PM
> > select S5P_SLEEP if PM
> >
> > @@ -176,8 +176,6 @@ config EXYNOS_SETUP_SPI
>
> Basically, I agree with your approach. Its CONFIG_ARCH_EXYNOSx depends
> on selecting own SOC.
>
> BTW, I'm thinking, which one selecting is better to us board? Or SoC?...
IMHO board selecting SoC selecting arch seems to represent reality the
best, because a board is based on particular SoC, which is based on
particular arch (family).
> > # machine support
> >
> > -if ARCH_EXYNOS4
> > -
>
> Well, according to removing above, we can select following exynos4210
> boards on other stuff. Of course, when select board, regarding soc is
> selected though. So I'm thinking I said as above.
Sorry, I'm not sure what you mean.
> > comment "EXYNOS4210 Boards"
> >
> > config MACH_SMDKC210
> >
> > @@ -397,7 +395,6 @@ config MACH_SMDK4412
> >
> > select MACH_SMDK4212
> > help
> >
> > Machine support for Samsung SMDK4412
> >
> > -endif
> >
> > comment "Flattened Device Tree based board for EXYNOS SoCs"
> >
> > diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> > index 8545069..c559609 100644
> > --- a/drivers/devfreq/Kconfig
> > +++ b/drivers/devfreq/Kconfig
> > @@ -67,7 +67,7 @@ comment "DEVFREQ Drivers"
> >
> > config ARM_EXYNOS4_BUS_DEVFREQ
> >
> > bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
> >
> > - depends on SOC_EXYNOS4210 || CPU_EXYNOS4212 || CPU_EXYNOS4412
> > + depends on ARCH_EXYNOS4
>
> I don't think so, because it depends on SoC not architecture. In
> addition, we don't know ARM_EXYNOS4_BUS_DEVFREQ is available on
> upcoming exynos4...
Hmm, good point, but wouldn't this apply as well to any Makefile option
using CONFIG_ARCH_EXYNOS4 at the moment? (e.g. clock-exynos4.o, dev-
audio.o, etc.)
Best regards,
Tomasz Figa
^ permalink raw reply
* [PATCH 3/4] ARM: EXYNOS: Kconfig: Group EXYNOS{4212, 4412} into EXYNOS4X12
From: Tomasz Figa @ 2012-10-23 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01d501cdb11b$ce824690$6b86d3b0$%kim@samsung.com>
On Tuesday 23 of October 2012 21:42:04 Kukjin Kim wrote:
> Tomasz Figa wrote:
> > This patch adds CONFIG_EXYNOS4X12, which is automatically selected
> > whenever there is at least one SoC from Exynos4x12 line enabled. All
> > the shared dependencies of EXYNOS{4212,4412} are moved to this new
> > option.
> >
> > This fixes build with Exynos4412 enabled and Exynos4212 and Exynos4210
> > disabled and also allows to simplify conditional compilation in
> > several
> > places.
> >
> > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> > ---
> >
> > arch/arm/mach-exynos/Kconfig | 15 +++++++++------
> > arch/arm/mach-exynos/Makefile | 2 +-
> > arch/arm/mach-exynos/common.h | 2 +-
> > drivers/cpufreq/Kconfig.arm | 2 +-
> > 4 files changed, 12 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/Kconfig
> > b/arch/arm/mach-exynos/Kconfig index 9f91892..6ea95f0 100644
> > --- a/arch/arm/mach-exynos/Kconfig
> > +++ b/arch/arm/mach-exynos/Kconfig
> > @@ -38,22 +38,25 @@ config SOC_EXYNOS4210
> >
> > help
> >
> > Enable EXYNOS4210 CPU support
> >
> > -config SOC_EXYNOS4212
> > - bool "SAMSUNG EXYNOS4212"
> > - default y
> > +config SOC_EXYNOS4X12
> > + def_bool n
> >
> > select ARCH_EXYNOS4
> > select SAMSUNG_DMADEV
> >
> > + select ARM_CPU_SUSPEND if PM
> >
> > select S5P_PM if PM
> > select S5P_SLEEP if PM
> >
> > +
> > +config SOC_EXYNOS4212
> > + bool "SAMSUNG EXYNOS4212"
> > + select SOC_EXYNOS4X12
> > + default y
> >
> > help
> >
> > Enable EXYNOS4212 SoC support
> >
> > config SOC_EXYNOS4412
> >
> > bool "SAMSUNG EXYNOS4412"
> >
> > - select ARCH_EXYNOS4
> > + select SOC_EXYNOS4X12
> >
> > default y
> >
> > - depends on ARCH_EXYNOS4
> > - select SAMSUNG_DMADEV
> >
> > help
> >
> > Enable EXYNOS4412 SoC support
> >
> > diff --git a/arch/arm/mach-exynos/Makefile
> > b/arch/arm/mach-exynos/Makefile index ceeb8c9..f88fcb6 100644
> > --- a/arch/arm/mach-exynos/Makefile
> > +++ b/arch/arm/mach-exynos/Makefile
> > @@ -16,7 +16,7 @@ obj-$(CONFIG_ARCH_EXYNOS) += common.o
> >
> > obj-$(CONFIG_ARCH_EXYNOS4) += clock-exynos4.o
> > obj-$(CONFIG_ARCH_EXYNOS5) += clock-exynos5.o
> > obj-$(CONFIG_SOC_EXYNOS4210) += clock-exynos4210.o
> >
> > -obj-$(CONFIG_SOC_EXYNOS4212) += clock-exynos4212.o
> > +obj-$(CONFIG_SOC_EXYNOS4X12) += clock-exynos4212.o
> >
> > obj-$(CONFIG_PM) += pm.o
> > obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
> >
> > diff --git a/arch/arm/mach-exynos/common.h
> > b/arch/arm/mach-exynos/common.h index 054c786..a8cb3e6 100644
> > --- a/arch/arm/mach-exynos/common.h
> > +++ b/arch/arm/mach-exynos/common.h
> > @@ -52,7 +52,7 @@ void exynos4210_register_clocks(void);
> >
> > #define exynos4210_register_clocks()
> > #endif
> >
> > -#ifdef CONFIG_SOC_EXYNOS4212
> > +#ifdef CONFIG_SOC_EXYNOS4X12
> >
> > void exynos4212_register_clocks(void);
> >
> > #else
> >
> > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> > index ca4ede3..d0ff91a 100644
> > --- a/drivers/cpufreq/Kconfig.arm
> > +++ b/drivers/cpufreq/Kconfig.arm
> > @@ -66,7 +66,7 @@ config ARM_EXYNOS4210_CPUFREQ
> >
> > SoC (S5PV310 or S5PC210).
> >
> > config ARM_EXYNOS4X12_CPUFREQ
> >
> > - def_bool (SOC_EXYNOS4212 || SOC_EXYNOS4412)
> > + def_bool SOC_EXYNOS4X12
> >
> > help
> >
> > This adds the CPUFreq driver for Samsung EXYNOS4X12
> > SoC (EXYNOS4212 or EXYNOS4412).
> >
> > --
> > 1.7.12
>
> Well, do we _really_ need to define CONFIG_SOC_EXYNOS4X12 for supporting
> common part of exynos4212 and exynos4412? In my opinion, it will cause
> confusion rather than reducing code size. Let's just use its own name
> for SoC.
There are files that must be compiled if any of these SoCs is enabled, for
example clock-exynos4212.o (it contains clocks for both of them regardless
of the misleading name).
This common Kconfig entry would be used in Makefiles for such cases.
Best regards,
Tomasz Figa
^ permalink raw reply
* [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
From: Felipe Balbi @ 2012-10-23 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351015771-6308-1-git-send-email-khilman@deeprootsystems.com>
Hi,
On Tue, Oct 23, 2012 at 11:09:31AM -0700, Kevin Hilman wrote:
> From: Kevin Hilman <khilman@ti.com>
>
> When debounce clocks are disabled, ensure that the banks
> dbck_enable_mask is cleared also. Otherwise, context restore on
> subsequent off-mode transition will restore previous value from the
> shadow copies (bank->context.debounce*) leading to mismatch state
> between driver state and hardware state.
>
> This was discovered when board code was doing
>
> gpio_request_one()
> gpio_set_debounce()
> gpio_free()
>
> which was leaving the GPIO debounce settings in a confused state.
> Then, enabling off mode causing bogus state to be restored, leaving
> GPIO debounce enabled which then prevented the CORE powerdomain from
> transitioning.
>
> Reported-by: Paul Walmsley <paul@pwsan.com>
> Cc: Igor Grinberg <grinberg@compulab.co.il>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
looks like this deserves a Cc: stable at vger.kernel.org tag.
> ---
> Applies on v3.7-rc2, targetted for v3.7.
>
> drivers/gpio/gpio-omap.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 94cbc84..dee2856 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -187,6 +187,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank *bank)
> * to detect events and generate interrupts at least on OMAP3.
> */
> __raw_writel(0, bank->base + bank->regs->debounce_en);
> + bank->dbck_enable_mask = 0;
shouldn't omap_gpio_restore_context() check for dbck_enabled instead of
the mask ? I mean:
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..b3a39a7 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1371,7 +1371,7 @@ static void omap_gpio_restore_context(struct gpio_bank *bank)
bank->base + bank->regs->dataout);
__raw_writel(bank->context.oe, bank->base + bank->regs->direction);
- if (bank->dbck_enable_mask) {
+ if (bank->dbck_enabled) {
__raw_writel(bank->context.debounce, bank->base +
bank->regs->debounce);
__raw_writel(bank->context.debounce_en,
the outcome would be the same, so it doesn't really matter. Just that,
at least to me, it would look better.
No strong feelings though.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/607d8ee1/attachment.sig>
^ permalink raw reply related
* [PATCH] i2c: omap: re-factor omap_i2c_init function
From: Felipe Balbi @ 2012-10-23 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351006039-24332-1-git-send-email-shubhrajyoti@ti.com>
Hi,
On Tue, Oct 23, 2012 at 08:57:19PM +0530, Shubhrajyoti D wrote:
> re-factor omap_i2c_init() so that we can re-use it for resume.
> While at it also remove the bufstate variable as we write it
> in omap_i2c_resize_fifo for every transfer.
>
> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> ---
> Applies on Felipe's series
> http://www.spinics.net/lists/linux-omap/msg79995.html
>
> Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
> on omap3636 beagle both idle and suspend.
>
> Functional testing on omap4sdp.
>
> drivers/i2c/busses/i2c-omap.c | 68 +++++++++++++++++------------------------
> 1 files changed, 28 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 5e5cefb..338cee7 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -209,7 +209,6 @@ struct omap_i2c_dev {
> u16 pscstate;
> u16 scllstate;
> u16 sclhstate;
> - u16 bufstate;
> u16 syscstate;
> u16 westate;
> u16 errata;
> @@ -285,9 +284,26 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg)
> }
> }
>
> +static void __omap_i2c_init(struct omap_i2c_dev *dev)
> +{
> +
> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
> + /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
> + omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
> +
> + /* SCL low and high time values */
> + omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
> + omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
> + if (dev->rev >= OMAP_I2C_REV_ON_3430_3530)
> + omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
> + /* Take the I2C module out of reset: */
> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
> + omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
> +
> +}
> static int omap_i2c_init(struct omap_i2c_dev *dev)
> {
> - u16 psc = 0, scll = 0, sclh = 0, buf = 0;
> + u16 psc = 0, scll = 0, sclh = 0;
> u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
> unsigned long fclk_rate = 12000000;
> unsigned long timeout;
> @@ -337,11 +353,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> * REVISIT: Some wkup sources might not be needed.
> */
> dev->westate = OMAP_I2C_WE_ALL;
> - omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
> - dev->westate);
> }
> }
> - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
>
> if (dev->flags & OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
> /*
> @@ -426,28 +439,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> sclh = fclk_rate / (dev->speed * 2) - 7 + psc;
> }
>
> - /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
> - omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
> -
> - /* SCL low and high time values */
> - omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
> - omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
> -
> - /* Take the I2C module out of reset: */
> - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
> -
> /* Enable interrupts */
> dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
> OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL) |
> ((dev->fifo_size) ? (OMAP_I2C_IE_RDR |
> OMAP_I2C_IE_XDR) : 0);
> - omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
> - if (dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
> - dev->pscstate = psc;
> - dev->scllstate = scll;
> - dev->sclhstate = sclh;
> - dev->bufstate = buf;
> - }
> +
> + dev->pscstate = psc;
> + dev->scllstate = scll;
> + dev->sclhstate = sclh;
> +
> + __omap_i2c_init(dev);
> +
> return 0;
> }
>
> @@ -1136,7 +1139,7 @@ omap_i2c_probe(struct platform_device *pdev)
> if (IS_ERR_VALUE(r))
> goto err_free_mem;
>
> - dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
> + dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
>
> dev->errata = 0;
>
> @@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
> {
> struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
>
> - if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
> - omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev->scllstate);
> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev->sclhstate);
> - omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev->bufstate);
> - omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev->syscstate);
> - omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev->westate);
> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
> - }
> -
> - /*
> - * Don't write to this register if the IE state is 0 as it can
> - * cause deadlock.
> - */
> - if (_dev->iestate)
> - omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev->iestate);
> + if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE)
> + __omap_i2c_init(_dev);
>
> return 0;
> }
another thing, the few places in omap_i2c_xfer_msg() which are currently
calling omap_i2c_init() should also be converted to call the newly added
__omap_i2c_init(). We don't need to recalculate any of those clock
dividers and whatnot.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/5d7bcaa9/attachment.sig>
^ permalink raw reply
* alignment faults in 3.6
From: Rob Herring @ 2012-10-23 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023165841.GX21164@n2100.arm.linux.org.uk>
On 10/23/2012 11:58 AM, Russell King - ARM Linux wrote:
> On Tue, Oct 23, 2012 at 12:30:14PM -0400, Jon Masters wrote:
>> On 10/05/2012 06:51 AM, Russell King - ARM Linux wrote:
>>
>> <snip switch out the might_fault __get_user for atomic
>> probe_kernel_address related discussion>
>>
>>> Okay, this should fix the issue... I've only compile tested it so far.
>>> Rob, as you have a way to trigger this easily, can you give this patch
>>> a go and let me know if it solves your problem? Thanks.
>>
>> Russell, can you let me know the status of this patch? I don't see it in
>> your tree, and I think I might have missed a followup patch from you? It
>> seems to solve a real problem with in-kernel faults during the dump_mem
>> in general, even beyond just an alignment fault.
>
> I was waiting for someone to say "I saw a problem and it works"...
> Would be nice to have a Tested-by tag against it...
I thought I had said it does work and fixes the problem. Anyway,
Tested-by: Rob Herring <rob.herring@calxeda.com>
Rob
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Kevin Hilman @ 2012-10-23 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAORVsuUkU3iTTFcXfYJ=_FntjiTR33Gs4z9OsNEn2Cxq7Ef-qA@mail.gmail.com>
Jean Pihet <jean.pihet@newoldbits.com> writes:
> Hi,
>
> On Sat, Oct 20, 2012 at 8:14 AM, Paul Walmsley <paul@pwsan.com> wrote:
>> Hi Jean
>>
>> On Fri, 19 Oct 2012, Paul Walmsley wrote:
>>
>>> On Thu, 18 Oct 2012, Paul Walmsley wrote:
>>>
>>> > Here are some basic OMAP test results for Linux v3.7-rc1.
>>> > Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
>>
>> ...
>>
>>> > Failing tests: needing investigation
>>> > ------------------------------------
>>> >
>>> > Boot tests:
>>>
>>> * 3530ES3 Beagle: I2C timeouts during userspace init
>>> - May be related to the threaded IRQ conversion of the I2C driver
>>> - Unknown cause
>>
>> This one turned out to be caused by:
>>
>> commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc
>> Author: Jean Pihet <jean.pihet@newoldbits.com>
>> Date: Thu Sep 20 18:08:03 2012 +0200
>>
>> ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
>>
>>
>> Reverting this commit causes the problem to go away, but since the OMAP PM
>> constraint code was removed as well, it's unlikely that a simple revert is
>> the right thing to do.
>>
>> Jean could you please investigate and fix this?
> I tried the latest l-o with omap2plus defconfig on my Beagleboard B5
> (ES2.1) and could not reproduce the problem.
> I do not have the I2C error messages at boot, nor at user space start
> up. I tried to read/write the TWL RTC, successfully.
>
> Another difference is the bootloader images. I have the following:
> - Texas Instruments X-Loader 1.4.2 (Feb 3 2009 - 15:34:17)
> - U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31)
> Could you send your bootloader images?
>
> I noticed you have I2C error messages in U-Boot, could that be the
> cause of the I2C lock-up?
FWIW, I have a relatively recent mainline u-boot+SPL:
U-Boot SPL 2012.04.01 (Jul 03 2012 - 07:07:04)
U-Boot 2012.04.01 (Jul 03 2012 - 07:07:04)
And I see I2C error messages from u-boot too:
timed out in wait_for_pin: I2C_STAT=0
I2C read: I/O error
I think these are normal/expected since u-boot may be looking for
expansion cards.
Kevin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox