While upgrading the kernel on a S3C2412 based board I've noted that it was
impossible to boot the board with a 2.6.32 or upper kernel.
I've tracked down the problem to the EBI virtual memory mapping that is in
conflict with the IO mapping definition in arch/arm/mach-s3c24xx/s3c2412.c.
Signed-off
Hi Mark,
We have posted following patch on the last week and received
your comment. So, We are implementing that use regmap API for I2C
and modify MFD driver of MAX77686 according to your comment.
[PATCH] MFD : add MAX77686 mfd driver
- https://lkml.org/lkml/2012/4/30/96
Additionally, We are int
Hi,
just a few nitpicks...
On 05/09/2012 06:24 PM, Yadwinder Singh wrote:
From: Yadwinder Singh Brar
Add support for PMIC/regulator portion of MAX77686 multifunction device.
MAX77686 provides LDOs[1-26] and BUCKs[1-9]. This is initial release of driver
which supports setting and getting the vo
On Wed, May 09, 2012 at 09:54:55PM +0530, Yadwinder Singh wrote:
> +/* Voltage maps in mV */
> +static const struct voltage_map_desc ldo_voltage_map_desc = {
> + .min = 800, .max = 3950,.step = 50, .n_bits = 6,
> +}; /* LDO3 ~ 5, 9 ~ 14, 16 ~ 26 */
Hrm, f
On Wed, May 09, 2012 at 09:54:54PM +0530, Yadwinder Singh wrote:
> +int max77686_read_reg(struct i2c_client *i2c, u8 reg, u8 *dest)
> +{
> + int ret;
> +
> + ret = i2c_smbus_read_byte_data(i2c, reg);
> + if (ret < 0)
It would really be better if this used the regmap API - the regulato
On Wed, May 09, 2012 at 09:54:53PM +0530, Yadwinder Singh wrote:
> This patch series adds support for max77686 which is a multifunction device
> which
> includes regulator (pmic), rtc and charger sub-blocks within it. The support
> for
> mfd driver and regulator driver are added by this patch ser
On 9 May 2012 22:28, Mark Brown wrote:
> On Wed, May 09, 2012 at 09:40:26PM +0800, Thomas Abraham wrote:
>> On 9 May 2012 16:52, Mark Brown wrote:
>
>> > This should've been squashed into the patch that updated to use driver
>> > data in order to avoid breaking bisection.
>
>> This patch updates
On 10 May 2012 00:47, Mark Brown wrote:
> On Thu, May 10, 2012 at 12:39:29AM +0800, Thomas Abraham wrote:
>> On 9 May 2012 22:32, Mark Brown wrote:
>
>> > Yeah, I know. I'm saying we should try to come up with a binding for
>> > this that can be used by new SPI contollers going forward so things
On Thu, May 10, 2012 at 12:39:29AM +0800, Thomas Abraham wrote:
> On 9 May 2012 22:32, Mark Brown wrote:
> > Yeah, I know. I'm saying we should try to come up with a binding for
> > this that can be used by new SPI contollers going forward so things are
> > consistent.
> Ok. For this patch seri
On 9 May 2012 22:32, Mark Brown wrote:
> On Wed, May 09, 2012 at 10:13:28PM +0800, Thomas Abraham wrote:
>> On 9 May 2012 17:07, Mark Brown wrote:
>> > On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote:
>
>> >> +- gpios: The gpio specifier for clock, mosi and miso interface lines (in
From: Yadwinder Singh Brar
Add support for PMIC/regulator portion of MAX77686 multifunction device.
MAX77686 provides LDOs[1-26] and BUCKs[1-9]. This is initial release of driver
which supports setting and getting the voltage of a regulator with I2C
interface.
Signed-off-by: Yadwinder Singh Brar
From: Yadwinder Singh Brar
MAX77686 is a mulitifunction device with PMIC, RTC and Charger on chip. This
driver provides common support for accessing the device. This is initial
version of this driver that supports to enable the chip with its primary I2C
bus.It also includes IRQ and device tree su
This patch series adds support for max77686 which is a multifunction device
which
includes regulator (pmic), rtc and charger sub-blocks within it. The support for
mfd driver and regulator driver are added by this patch series. This patch
series
also includes device tree and irqdomain support for
On 9 May 2012 22:33, Mark Brown wrote:
> On Wed, May 09, 2012 at 10:22:26PM +0800, Thomas Abraham wrote:
>> On 9 May 2012 18:55, Mark Brown wrote:
>
>> > Yes, that's the normal way of handling this and is actually what the
>> > code was originally doing - there's a bunch of ifdefed devices in
>>
On Wed, May 09, 2012 at 10:22:26PM +0800, Thomas Abraham wrote:
> On 9 May 2012 18:55, Mark Brown wrote:
> > Yes, that's the normal way of handling this and is actually what the
> > code was originally doing - there's a bunch of ifdefed devices in
> > plat-samsung/devs.c. You usually have to do
On Wed, May 09, 2012 at 10:13:28PM +0800, Thomas Abraham wrote:
> On 9 May 2012 17:07, Mark Brown wrote:
> > On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote:
> >> +- gpios: The gpio specifier for clock, mosi and miso interface lines (in
> >> no
> >> + particular order). The forma
On Wed, May 09, 2012 at 09:40:26PM +0800, Thomas Abraham wrote:
> On 9 May 2012 16:52, Mark Brown wrote:
> > This should've been squashed into the patch that updated to use driver
> > data in order to avoid breaking bisection.
> This patch updates clock devname in the platform code and the
> mod
On 9 May 2012 18:55, Mark Brown wrote:
> On Wed, May 09, 2012 at 11:10:14AM +0200, Heiko Stübner wrote:
>
>> Similar to the adc and rtc driver, all Samsung platforms reuse a common
>> platform-device definition for the s3c64xx-spi and simply will set the
>> correct
>> name when the machine type i
On 9 May 2012 17:07, Mark Brown wrote:
> On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote:
>
>> +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no
>> + particular order). The format of the gpio specifier depends on the gpio
>> + controller.
>
> This seems
On 9 May 2012 16:52, Mark Brown wrote:
> On Wed, May 09, 2012 at 03:34:49AM +0530, Thomas Abraham wrote:
>> With the addition of platform specific driver data in the spi-s3c64xx
>> driver, the device name of spi controllers are changed. Accordingly,
>> update the device name of spi clocks instance
Russell King - ARM Linux wrote:
>
> On Wed, Apr 25, 2012 at 11:21:47AM +, Arnd Bergmann wrote:
> > Note that the point of the DEFINE_RES_*() macros is really to prevent
> > people from coming up with new silly macros to do the same thing, as
> > we've had in the past.
>
> One of the other rea
struct generic_pm_domain already has a field for name. Use that field
instead of creating another field in struct exynos_pm_domain
Signed-off-by: Sangwook Lee
---
arch/arm/mach-exynos/pm_domains.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos
On 9 May 2012 01:36, Zhang, Rui wrote:
> Hi, Amit,
>
> Sorry for the late response as I'm in a travel recently.
>
> I think the generic cpufreq cooling patches are good.
>
> But about the THERMAL_TRIP_STATE_INSTANCE patch, what I'd like to see is that
> 1. from thermal zone point of view, when the
Heiko Stübner wrote:
>
> From: Tushar Behera
>
> CC: Ben Dooks
> CC: Kukjin Kim
> Signed-off-by: Tushar Behera
> Signed-off-by: Heiko Stuebner
> ---
> changes since v1: update the patch to apply against the moved dev-uart
> devices
> As this patch does not touch anything else apart from the
Heiko Stübner wrote:
>
> Again the series of small moves of common code from the plat-s3c24xx to
> the
> mach-s3c24xx directory.
>
> This time without the wrong handled irq.c . Hopefully I'll get time to do
> it
> properly later.
>
> As the dev-uart.c move breaks the resource patch by Tushar Beh
From: Changhwan Youn
The sequence of cpu_enter_lowpower() for Cortex-A15
is different from the sequence for Cortex-A9.
This patch implements cpu_enter_lowpower() for EXYNOS5
SoC which has Cortex-A15 cores.
Signed-off-by: Changhwan Youn
Cc: Russell King
Signed-off-by: Kukjin Kim
---
Note, I di
Daniel Lezcano wrote:
>
> On 05/09/2012 01:53 PM, Kukjin Kim wrote:
> > amit kachhap wrote:
> >>
> >> Hi Mr Kukjin,
> >>
> >> Any comment or update about this patch?
> >>
> > I'm not sure we don't need to check the idle_time?
> > Others, looks ok to me.
>
> Hi,
>
> may be I misunderstood your qu
On 05/09/2012 01:53 PM, Kukjin Kim wrote:
amit kachhap wrote:
Hi Mr Kukjin,
Any comment or update about this patch?
I'm not sure we don't need to check the idle_time?
Others, looks ok to me.
Hi,
may be I misunderstood your question but the behavior is not changed
here, just the code is r
amit kachhap wrote:
>
> Hi Mr Kukjin,
>
> Any comment or update about this patch?
>
I'm not sure we don't need to check the idle_time?
Others, looks ok to me.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> Regards,
>
Thomas Abraham wrote:
>
> This patch series adds support for Samsung's Exynos5250 Rev1.0. It
> includes
> fixes for device tree support, updates for rev1.0 silicon and device tree
> discovery for combiner and wakeup interrupt controller. This patch series
> depricates the existing support for Exyn
Thomas Abraham wrote:
>
> From: Kisoo Yu
>
> The fout clock of BPLL and MPLL have a selectable source in rev1 of
> EXYNOS5. The clock options are a fixed divided by 2 clock and the
> output of the PLL itself. Add support for these new clock instances.
>
> Signed-off-by: Kisoo Yu
> Signed-off-b
According to PWM hardware spec, the actual period which
has been calculated by period and input clock is same
with (tcnt + 1), so need to down count for tcnt register.
And current PWM HW checks the compare register after
tcmp++ internally in hardware.
Signed-off-by: Kukjin Kim
---
arch/arm/plat
On Wed, May 09, 2012 at 11:10:14AM +0200, Heiko Stübner wrote:
> Similar to the adc and rtc driver, all Samsung platforms reuse a common
> platform-device definition for the s3c64xx-spi and simply will set the
> correct
> name when the machine type is determined during boot.
Right, that doesn'
On 9 May 2012 14:50, Heiko Stübner wrote:
> Am Mittwoch, 9. Mai 2012, 00:04:51 schrieb Thomas Abraham:
>> The set_level callback in the controller data, which is used to configure
>> the slave select line, cannot be supported when migrating the driver to
>> device tree based discovery. Since all t
On 9 May 2012 01:46, Andrew Morton wrote:
> On Tue, 8 May 2012 21:48:17 +0530
> Amit Daniel Kachhap wrote:
>
>> This code added creates a link between temperature sensors, linux thermal
>> framework and cooling devices for samsung exynos platform. This layer
>> monitors the temperature from the
Am Mittwoch, 9. Mai 2012, 00:04:51 schrieb Thomas Abraham:
> The set_level callback in the controller data, which is used to configure
> the slave select line, cannot be supported when migrating the driver to
> device tree based discovery. Since all the platforms currently use gpio
> as the slave s
Am Mittwoch, 9. Mai 2012, 10:56:17 schrieb Mark Brown:
> On Wed, May 09, 2012 at 03:34:50AM +0530, Thomas Abraham wrote:
> > + s3c64xx_spi0_set_platdata("s3c6410-spi", NULL, 0, 1);
>
> Shouldn't we just set the name in the struct platform_device rather than
> requiring the machine to pass it thr
On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote:
> +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no
> + particular order). The format of the gpio specifier depends on the gpio
> + controller.
This seems odd... This isn't a bitbanging controller, and s
On Wed, May 09, 2012 at 03:34:50AM +0530, Thomas Abraham wrote:
> + s3c64xx_spi0_set_platdata("s3c6410-spi", NULL, 0, 1);
Shouldn't we just set the name in the struct platform_device rather than
requiring the machine to pass it through by hand?
--
To unsubscribe from this list: send the line
On Wed, May 09, 2012 at 03:34:49AM +0530, Thomas Abraham wrote:
> With the addition of platform specific driver data in the spi-s3c64xx
> driver, the device name of spi controllers are changed. Accordingly,
> update the device name of spi clocks instances.
This should've been squashed into the pat
On 9 May 2012 01:46, Andrew Morton wrote:
> On Tue, 8 May 2012 21:48:14 +0530
> Amit Daniel Kachhap wrote:
>
>> This patch adds support for generic cpu thermal cooling low level
>> implementations using frequency scaling up/down based on the registration
>> parameters. Different cpu related cool
On Wed, May 9, 2012 at 3:34 AM, Thomas Abraham
wrote:
> This patch series adds device tree based discovery support for Samsung's
> s3c64xx compatible spi controller. This is mainly tested for Exynos4210
> and Exynos5250 with onboard spi nor flash device.
>
> This patch series is based on Linux 3.4
On Wed, May 9, 2012 at 3:34 AM, Thomas Abraham
wrote:
>
> The set_level callback in the controller data, which is used to configure
> the slave select line, cannot be supported when migrating the driver to
> device tree based discovery. Since all the platforms currently use gpio
> as the slave sel
43 matches
Mail list logo