RE: [PATCH 0/4] ARM: Exynos4: NURI and UniversalC210 fixes for v3.4-rc2
Hi Kukjin, On Saturday, April 14, 2012 5:50 PM Kukjin Kim wrote: > >>> I've just checked the support for Samsung NURI and UniversalC210 boards > >>> in v3.4-rc1 and found some issues. The attached patches fixes the > >>> leftovers from missing s3c-sdhci driver changes, fixes division by > >>> zero caused by missing initial value for xusbxti clock and removes broken > >>> optional configuration entries for touch screen driver. It would be great > >>> if the attached patches will get merged to v3.4-rcX series. > >>> > >> OK, looks good to me, applied. > > > > Huh, it doesn't look that easy... > > > > I've just noticed that v3.4-rc2 comes with missing s3c-sdhci driver patches > > (see commit 1ddca05743525), so you need a bit more work on your fixes branch > > to get sdhci working again. Please restore patches 'ARM: EXYNOS: use > > 'exynos4-sdhci' as device name for sdhci controllers' and 'ARM: SAMSUNG: > > remove all uses of clk_type member in sdhci platform data' as well as the > > other patches which fixes issues after changing the name of sdhci platform > > devices from s3c-sdhci to exynos4-sdhci. My patch 'ARM: EXYNOS: fix SDHCI > > support on NURI and UniversalC210 boards' should be dropped then. > > > > If you have any problems, let me know, I have them already collected and > > rebased onto v3.4-rc2, so I can resend an updated version. > > Thanks for your reminder. I re-worked Thomas' patches you said for it > and you can check it in my -next and -fixes-3 and I'm looking at that. Thanks, now it is much better. The only missing thing are host_caps2 entry updates, which I've posted a few minutes ago in '[PATCH for v3.4-rc3] ARM: Samsung: add missing MMC_CAP2_BROKEN_VOLTAGE capability' mail. I would also like to remind that UniversalC210 board requires 'ARM: Exynos4: use s5p-timer for UniversalC210 board' bugfix/workaround to work with recent kernels. Any chance to get this patch merged? It has been (re)posted many times since v3.2-rc1 if I remember correctly... Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH for v3.4-rc3] ARM: Samsung: add missing MMC_CAP2_BROKEN_VOLTAGE capability
Commit 6e8201f57c935 "mmc: core: add the capability for broken voltage"
introduced a new quirk to indicate that MMC core should ignore voltage
change errors reported by the regulators core. This is required to get
SDHCI working on UniversalC210, NURI and GONI boards again after commit
ceb6143b2df81c ("mmc: sdhci: fix vmmc handling").
Signed-off-by: Marek Szyprowski
Signed-off-by: Kyungmin Park
---
arch/arm/mach-exynos/mach-nuri.c |1 +
arch/arm/mach-exynos/mach-universal_c210.c |1 +
arch/arm/mach-s5pv210/mach-goni.c |2 ++
3 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index 91e5986..021dc68 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -112,6 +112,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
__initdata = {
.host_caps = (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
MMC_CAP_ERASE),
+ .host_caps2 = MMC_CAP2_BROKEN_VOLTAGE,
.cd_type= S3C_SDHCI_CD_PERMANENT,
};
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index ef706e9..add55b4 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -747,6 +747,7 @@ static struct s3c_sdhci_platdata universal_hsmmc0_data
__initdata = {
.max_width = 8,
.host_caps = (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA |
MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED),
+ .host_caps2 = MMC_CAP2_BROKEN_VOLTAGE,
.cd_type= S3C_SDHCI_CD_PERMANENT,
};
diff --git a/arch/arm/mach-s5pv210/mach-goni.c
b/arch/arm/mach-s5pv210/mach-goni.c
index a8933de..3239566 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -765,6 +766,7 @@ static void __init goni_pmic_init(void)
/* MoviNAND */
static struct s3c_sdhci_platdata goni_hsmmc0_data __initdata = {
.max_width = 4,
+ .host_caps2 = MMC_CAP2_BROKEN_VOLTAGE,
.cd_type= S3C_SDHCI_CD_PERMANENT,
};
--
1.7.1.569.g6f426
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/6] thermal: exynos: Add kernel thermal support for exynos platform
On 三, 2012-04-11 at 18:17 +0530, Amit Kachhap wrote:
> Hi Rui,
>
> Thanks for looking into the patches.
>
> On 10 April 2012 06:28, Zhang Rui wrote:
> > Hi, Amit,
> >
> > On 三, 2012-04-04 at 10:02 +0530, Amit Kachhap wrote:
> >> Hi Len/Rui,
> >>
> >> Any comment or feedback from your side about the status of this patch?
> >> Is it merge-able or major re-work is needed? I have fixed most of the
> >> comments in this patchset and currently working on some of the minor
> >> comments received and will submit them shortly.
> >>
> > Sorry for the late response.
> >
> > First of all, it makes sense to me to introduce the generic cpufrq
> > cooling implementation.
> ok thanks
> > But I still have some questions.
> > I think the key reason why THERMAL_TRIP_STATE_INSTANCE is introduced is
> > that the MONIROR_ZONE and WARN_ZONE on exynos4 can not fit into the
> > current passive handling in the generic thermal layer well, right?
> > e.g. there is no tc1/tc2 on exynos4.
> >
> > If yes, is it possible that we can enhance the passive cooling to
> > support the generic processor cooling?
> > say, introduce another way to throttle the processor in
> > thermal_zone_device_passive when tc1 and tc2 are not available?
>
> I agree that this new trip type code can be moved into passive trip
> type when tc1 and tc2 are 0. but this is special type of cooling
> devices behaviour where only instances of the same cooling device is
> binded to a trip point. The order of mapping is the only
> differentiating criteria and there are some checks used to implement
> this like
> 1) The trip points should be in ascending order.(This is missing in my
> original patch, so I added below)
> 2) The set_cur_state has to be called for the exact temp range so
> get_cur_state(&state) and set_cur_state(state ++/state--) logic is not
> possible.
> 3) set_cur_state is called as set_cur_state(cdev_instance).
Do you really need two THERMAL_TRIP_STATE_INSTANCE trip points?
I'm not sure if my understanding is right, but IMO, we can have one
THERMAL_TRIP_STATE_INSTANCE only, for both MONIROR_ZONE and WARN_ZONE,
and the trip temperature equals MONIROR_ZONE.
The cpufreq cooling device will work in the same way, no?
thanks,
rui
> There is a chance that people might confuse that these checks are
> applicable for passive trip types also which is not the case here.
>
> @@ -1187,6 +1228,21 @@ struct thermal_zone_device
> *thermal_zone_device_register(char *type,
> tz->ops->get_trip_type(tz, count, &trip_type);
> if (trip_type == THERMAL_TRIP_PASSIVE)
> passive = 1;
> + /*
> +* For THERMAL_TRIP_STATE_INSTANCE trips, thermal zone should
> +* be in ascending order.
> + */
> + if (trip_type == THERMAL_TRIP_STATE_INSTANCE) {
> + tz->ops->get_trip_temp(tz, count, &trip_temp);
> + if (first_trip_temp == 0)
> + first_trip_temp = trip_temp;
> + else if (first_trip_temp < trip_temp)
> + first_trip_temp = trip_temp;
> + else if (first_trip_temp > trip_temp) {
> + pr_warn("Zone trip points should be in
> ascending order\n");
> + goto unregister;
> + }
> + }
> }
>
> if (!passive)
>
> Anyway there is other alternative where this new trip type is not
> needed and I can just use the existing trip type THERMAL_TRIP_ACTIVE
> and create 2 separate cooling devices for MONITOR_ZONE and WARN_ZONE.
> I had thought to make this generic and just to manage with 1 cooling
> device.
> What is your view?
>
> Thanks,
> Amit Daniel
>
>
> >
> > thanks,
> > rui
> >
> >> Regards,
> >> Amit Daniel
> >>
> >> On 19 March 2012 11:47, Amit Daniel Kachhap
> >> wrote:
> >> > Changes since V1:
> >> > *Moved the sensor driver to driver/thermal folder from driver/hwmon
> >> > folder
> >> > as suggested by Mark Brown and Guenter Roeck
> >> > *Added notifier support to notify the registered drivers of any cpu
> >> > cooling
> >> > action. The driver can modify the default cooling behaviour(eg set
> >> > different
> >> > max clip frequency).
> >> > *The percentage based frequency replaced with absolute clipped frequency.
> >> > *Some more conditional checks when setting max frequency.
> >> > *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
> >> > THERMAL_TRIP_STATE_INSTANCE
> >> > *Many review comments from R, Durgadoss and
> >> > eduardo.valen...@ti.com implemented.
> >> > *Removed cooling stats through debugfs patch
> >> > *The V1 based can be found here,
> >> > https://lkml.org/lkml/2012/2/22/123
> >> > http://lkml.org/lkml/2012/3/3/32
> >> >
> >> > Changes since RFC:
> >> > *Changed the cpu cooling registration/unregistration API's to instance
> >> > based
> >> > *Changed the STATE_ACTIVE
