Tomasz,
On Fri, May 17, 2013 at 1:34 PM, Tomasz Figa wrote:
>> Slight nit to add this before the call to irq_domain_add_linear().
>> demv() will handle freeing your memory but nothing will handle undoing
>> the irq_domain_add_linear() if you return an error.
>
> I'm a bit sceptical when it is abo
need to solve.
I wouldn't be opposed to a re-spin to address some of the above, but I
also won't object to this landing and remaining issues being addressed
in future patches. This patch definitely does make things better and
no worse. :)
On exynos5250-snow (pinmux backported to 3.8)
:)
Just nits / optional comments below, so on exynos5250-snow (pinmux
backported to 3.8):
Tested-by: Doug Anderson
Reviewed-by: Doug Anderson
> @@ -229,6 +235,11 @@ static int exynos_eint_gpio_init(struct
> samsung_pinctrl_drv_data *d)
> dev_err(d
-by: Kyungmin Park
> ---
> drivers/pinctrl/pinctrl-samsung.h | 1 +
> 1 file changed, 1 insertion(+)
Sure. Seems like it could be squashed into the next patch, but I
think it looks fine separate too.
On exynos5250-snow (pinmux backported to 3.8):
Tested-by: Doug Anderson
Reviewed-by: Doug Ander
4x0 (or even if I'm
misunderstanding and they're already handled somehow), I don't see any
problems with this patch, so...
On exynos5250-snow (pinmux backported to 3.8):
Tested-by: Doug Anderson
Reviewed-by: Doug Anderson
--
To unsubscribe from this list: send the line &quo
Tomasz,
On Fri, May 17, 2013 at 9:24 AM, Tomasz Figa wrote:
> This patch makes legacy code on suspend/resume path being executed
> conditionally, on non-DT platforms only, to fix suspend/resume of
> DT-enabled systems, for which the code is inappropriate.
>
> Signed-off-by: Tomasz Figa
> Signed-
mux backported to 3.8):
Tested-by: Doug Anderson
Reviewed-by: Doug Anderson
On Fri, May 17, 2013 at 9:24 AM, Tomasz Figa wrote:
> On DT-enabled systems pinctrl-exynos driver is responsible for handling
> of wake-up EINT interrupts. This patch adjusts wake-up mask
> configuration co
pinctrl-exynos.c | 23 +++
> 1 file changed, 23 insertions(+)
On exynos5250-snow (pinmux backported to 3.8):
Tested-by: Doug Anderson
Reviewed-by: Doug Anderson
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kerne
Tomasz,
On Fri, May 17, 2013 at 5:38 AM, Tomasz Figa wrote:
>> You might want to have a debugfs file in your driver for inspecting
>> them though, that sounds like it could be helpful. I'd recommend
>> augmenting your .pin_config_dbg_show() callback in the
>> struct pinconf_ops to display this fo
powerdown state.
Patch originally from Prathyush K but
rewritten by Doug Anderson .
Signed-off-by: Prathyush K
Signed-off-by: Doug Anderson
---
Changes in v3:
- Skip save and restore for banks with no powerdown config.
Changes in v2:
- Now uses sycore_ops to make sure we're early enough.
Tomasz,
On Thu, May 16, 2013 at 4:10 PM, Doug Anderson wrote:
> If state of these registers isn't lost on those SoCs then running the
> save/restore shouldn't _hurt_ though, right? If you can run the old
> GPIO code on one of those systems and do a suspend/resume you could
Tomasz,
On Thu, May 16, 2013 at 3:37 PM, Tomasz Figa wrote:
> Well, to make long story short, including headers from plat/ and mach/
> from files outside plat/ or mach/ is no longer valid with
> CONFIG_MULTIPLATFORM, because more than one plat and/or mach can be
> enabled at the same time. In add
powerdown state.
Patch originally from Prathyush K but
rewritten by Doug Anderson .
Signed-off-by: Prathyush K
Signed-off-by: Doug Anderson
---
Changes in v2:
- Now uses sycore_ops to make sure we're early enough.
- Try to handle two CON registers better.
- Should handle s3c24xx better a
Tomasz,
On Thu, May 16, 2013 at 3:56 PM, Tomasz Figa wrote:
> Seems like I need some sleep, as I'm already starting to overlook large
> blobs of code.
>
> Originally, GPIO suspend/resume handlers have been configured in
> drivers/gpio/gpio-samsung.c, by setting pm field of samsung_gpio_chip
> str
Tomasz,
On Thu, May 16, 2013 at 12:26 PM, Tomasz Figa wrote:
> On Thursday 16 of May 2013 10:12:32 Doug Anderson wrote:
>> From: Prathyush K
>>
>> Add the irq_set_wake function for exynos pinctrl to configure the
>> external interrupt wakeup mask register.
>>
&g
Tomasz,
On Thu, May 16, 2013 at 2:27 PM, Tomasz Figa wrote:
> OK. I will be fine to go with your patches, after addressing the comments.
> In the end it's good that you posted them, as reviewing them allowed me to
> find even better ways of doing some things than I had in mine ;) .
Yes. I often
Tomasz,
Thanks for the review! I'll get a new patch out either today or tomorrow...
On Thu, May 16, 2013 at 12:19 PM, Tomasz Figa wrote:
>> +/**
>> + * samsung_pinctrl_resume_noirq - save pinctrl state for suspend
>> + *
>> + * Save data for all banks handled by this device.
>> + */
>> +static
Tomasz / Stephen,
On Wed, May 15, 2013 at 5:55 PM, Doug Anderson wrote:
>> Also after reading Stephen's reply, I'm wondering if hogging wouldn't
>> solve the problem indeed. (It might have to be fixed on pinctrl-samsung
>> first, as last time I tried to use it, i
From: Prathyush K
Add the irq_set_wake function for exynos pinctrl to configure the
external interrupt wakeup mask register.
[dianders: minor nit fixes; port to ToT]
Signed-off-by: Prathyush K
Signed-off-by: Doug Anderson
---
drivers/pinctrl/pinctrl-exynos.c | 45
samsung_gpio_pm_2bit_resume(), which seemed to
do this a reasonable way.
Patch originally from Prathyush K but
rewritten by Doug Anderson .
Signed-off-by: Prathyush K
Signed-off-by: Doug Anderson
---
drivers/pinctrl/pinctrl-samsung.c | 199 ++
drivers/pinctrl/pinctrl-samsung.h
tps://gerrit.chromium.org/gerrit/#/c/51342/3
Doug Anderson (1):
pinctrl: samsung: fix suspend/resume functionality
Prathyush K (1):
pinctrl: exynos: fix eint wakeup by using irq_set_wake()
drivers/pinctrl/pinctrl-exynos.c | 45 ++---
drivers/pinctrl/pinctrl-exynos.h | 3 +-
drivers/
Tomasz,
On Wed, May 15, 2013 at 5:19 PM, Tomasz Figa wrote:
> Hmm, last thing before I fell asleep: We already have support for power
> down configuration in pinctrl-samsung. See samsung,pin-conpdn and
> samsung,pin-pudpdn.
Dang it! OK, we'll work on using those.
> Also I already have patches
Tomasz,
On Wed, May 15, 2013 at 5:13 PM, Tomasz Figa wrote:
> I don't have anything interesting at the moment. It's a bit late now here
> (2 AM), so I'm going to get some sleep first.
Sorry for keeping you up. Sleep is good!
> Also after reading Stephen's reply, I'm wondering if hogging would
Stephen,
On Wed, May 15, 2013 at 4:51 PM, Stephen Warren wrote:
> I don't really see much disadvantage here; the interrupt bindings
> specify things related to interrupts and the pinctrl bindings specify
> thing related to pin configuration.
OK. If this is the best way then I can accept that an
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa wrote:
> Yes. I don't like the current way too much either, duplication being one
> of the reasons.
Do you have any other ideas? It sounds like Linus didn't like my
suggestion and makes some good points...
I don't have any other grea
Tomasz,
On Wed, May 15, 2013 at 2:41 PM, Tomasz Figa wrote:
> This will be hard, since the phandle in interrupt-parent is represented by
> an IRQ domain in kernel code. One-interrupt IRQ domains seem a bit awkward
> to me.
>
> Since we are already going to modify the binding, let's think a bit mo
Tomasz,
On Wed, May 15, 2013 at 2:36 PM, Tomasz Figa wrote:
>> One potential reason for leaving them is the hopes that it might cause
>> a little less line glitching, especially in the case of outputs.
>> There is some delay between the pinmux being configured at the start
>> of device probe and
Linus,
Thank you for your comments. See below...
Stephen: sorry for missing you earlier! :(
On Wed, May 15, 2013 at 11:29 AM, Linus Walleij
wrote:
> But please use the preprocessor to provide symbolic names for
> the configurations. See for example these two patches from
> J-C:
> http://www.m
Tomasz,
Thanks for your comments. I'm glad I'm not totally off-track. I'll
respond to most things in reply to Linus' email, but a few here:
On Wed, May 15, 2013 at 10:26 AM, Tomasz Figa wrote:
>> pinctrl@1140 {
>> cyapa_irq: cyapa-irq {
>> samsung,pins = "gpx1-2";
>> sams
Linus,
I'm currently working towards adapting exynos5250-snow (the ARM
Chromebook) to work well in the new world of pinctrl. We've got a
backport of exynos5250 pinctrl in our kernel-3.8 tree and are now
fixing all of the bugs that have popped up. Patches will be sent
upstream (where applicable)
suggest moving this to exynos5250.dtsi but then
realized that I saw a board recently that used a non-standard HPD pin
recently! ...so keeping it in the board file (like you've done) is
good.
...so looks good to me.
Reviewed-by: Doug Anderson
--
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
++
> 1 files changed, 6 insertions(+), 0 deletions(-)
Thanks for updating the bindings. This looks good.
Reviewed-by: Doug Anderson
--
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
Tested on Exynos5250
>
> arch/arm/boot/dts/exynos5250.dtsi |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
Clock number matches clock bindings for 5250 and clock name matches dp
driver, so this looks good.
Reviewed-by: Doug Anderson
--
To unsubscribe from this list: send the l
7;s following patch.
> "[PATCH] ARM: exynos: defconfig update"
> https://lkml.org/lkml/2013/5/9/455
>
> arch/arm/configs/exynos_defconfig |6 ++
> 1 file changed, 6 insertions(+)
Your changes also look good to me.
Reviewed-by: Doug Anderson
--
To unsubscribe from thi
s5440. Also add basic dependencies for the PINCTRL_EXYNOS
kernel config.
Signed-off-by: Doug Anderson
---
Changes in v3:
- Moved to chip level as per Tomasz.
- Update PINCTRL Kconfig for exynos.
Changes in v2:
- Moved to the arch level as suggested by Olof.
arch/arm/mach-exynos/Kconfi
Tomasz / Olof,
On Thu, May 9, 2013 at 2:45 AM, Tomasz Figa wrote:
>> Nothing stops you from doing that on your own. I tend to push back
>> onto the maintainers to get them engaged in their own housekeeping,
>> but anyone is free to :)
I will probably leave this to the maintainers at this point..
code) will eventually move over to the common code.
Signed-off-by: Doug Anderson
---
Changes in v2:
- Moved to the arch level as suggested by Olof.
arch/arm/mach-exynos/Kconfig | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/m
Olof,
On Wed, May 8, 2013 at 11:19 AM, Olof Johansson wrote:
> Seems like this should be selected by the SoC (ARCH_EXYNOS5) instead
> of the board. Actually, I'm not sure we need the board Kconfig entry
> long-term; all boards will be dt-only.
Good point. Hopefully someone at Samsung can work o
If you've got MACH_EXYNOS5_DT but not MACH_EXYNOS4_DT you'll be
missing the pincontrol definitions. Add them for exynos5.
Signed-off-by: Doug Anderson
---
arch/arm/mach-exynos/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/m
ion path should fix the issues
> reported in above referenced commit. The changes committed during the
> earlier patch has also been reverted here.
>
> Signed-off-by: Tushar Behera
> CC: Doug Anderson
> ---
> Doug,
>
> Would you please test whether this patch works for Snow?
Hi,
On Mon, Apr 8, 2013 at 12:22 AM, Kukjin Kim wrote:
> Mike Turquette wrote:
>>
>> Quoting Tushar Behera (2013-04-02 01:20:40)
>> > In legacy setup, sclk_mmc{0,1,2,3} used PRE_RATIO bit-field (8-bit wide)
>> > instead of RATIO bit-field (4-bit wide) for dividing clock rate.
>> >
>> > With curre
From: Thomas Abraham
With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.
Signed-off-by: Thomas Abraham
Signed-off-by: Doug Anderson
Acked-by: Linus Walleij
Reviewed-by: Doug Anderson
Mark,
On Mon, Mar 11, 2013 at 10:36 AM, Doug Anderson wrote:
> Thomas,
>
> On Wed, Mar 6, 2013 at 3:42 AM, Thomas Abraham
> wrote:
>> With device core now able to setup the default pin configuration,
>> the pin configuration code based on the deprecated Samsung spec
Naveen,
On Fri, Apr 12, 2013 at 9:36 PM, Naveen Krishna Ch
wrote:
> Can some one review this and get this fix into the tree.
I think the ball is in your court. Lars responded to your RFC patch
here and requested that you do a reset of the bus in the case of being
interrupted.
https://lkml.org/
Thomas,
On Wed, Apr 10, 2013 at 6:56 AM, Doug Anderson wrote:
> On Wed, Apr 10, 2013 at 5:48 AM, Thomas Abraham
> wrote:
>> The call to regulator_enable() is prior to the call to mmc_add_host().
>> Hence, call to mmc_fre_host is not required in this case. So the above
>>
Thomas,
On Wed, Apr 10, 2013 at 5:48 AM, Thomas Abraham
wrote:
> The call to regulator_enable() is prior to the call to mmc_add_host().
> Hence, call to mmc_fre_host is not required in this case. So the above
> change should be right.
Are you sure that mmc_free_host() is the opposite of mmc_add_
Thomas,
On Mon, Apr 8, 2013 at 10:59 PM, Thomas Abraham
wrote:
> @@ -2002,7 +1994,7 @@ static int dw_mci_init_slot(struct dw_mci *host,
> unsigned int id)
> if (ret) {
> dev_err(host->dev,
> "failed to enable regulator: %d\n
Tomasz,
On Mon, Apr 8, 2013 at 12:27 PM, Tomasz Figa wrote:
> Common Clock Framework by default automatically gates unused clocks, just
> like regulator core does with unused regulators. Maybe this is the cause?
Yes, I'm nearly certain that's the case here. The reset code doesn't
belong to any
Kukjin,
On Mon, Apr 8, 2013 at 11:29 AM, Kukjin Kim wrote:
> BTW, if any problems on current for-next, please kindly let me know.
I usually try to check linux-next at least once a week, but sometimes
it's more or less often. At the moment I'm trying to track something
weird down but it seems li
Kukjin,
On Mon, Apr 8, 2013 at 11:23 AM, Kukjin Kim wrote:
> Thanks for your pointing out. But it should be fixed with re-sorting out the
> branch.
No problem with however you want to solve it. ;) Seemed that the
patch was the easiest way to report the problem in any case...
-Doug
--
To unsub
[<80633a8c>] (kernel_init_freeable+0x108/0x1d0) from [<8046d2f8>]
(kernel_init+0x1c/0xf4)
[<8046d2f8>] (kernel_init+0x1c/0xf4) from [<8000e358>]
(ret_from_fork+0x14/0x20)
---[ end trace 4bcdc801c868d73f ]---
Signed-off-by: Doug Anderson
---
arch/arm/boot/dts/exynos5250.dt
The display timing node was added:
7ed2077 ARM: dts: Add display timing node to exynos5250-smdk5250.dts
...and looks OK there. ...but it looks like we lost a "};" in the
merge and it no longer compiles. Fix it.
Signed-off-by: Doug Anderson
---
arch/arm/boot/dts/exynos5250-smdk52
Thomas,
Since I commented on previous versions of this patch, I would have
loved to have been CCed on this new version. ;)
On Fri, Apr 5, 2013 at 6:53 AM, Thomas Abraham
wrote:
> With device core now able to setup the default pin configuration,
> the pin configuration code based on the deprecat
Lars,
On Fri, Apr 5, 2013 at 1:53 AM, Lars-Peter Clausen wrote:
> Since we sleep inside the protected section we need to use a mutex.
Ah, good point.
> It's not the timeout case I'm worried about, but the case where the transfer
> is interrupted by the user. Even though it is rather unlikely fo
Kukjin,
On Tue, Apr 2, 2013 at 7:16 PM, Kukjin Kim wrote:
>> Applied with 1st one, BTW, do you want to send this for stable tree?
I don't have any need for it to be in stable tree. The ARM Chromebook
hasn't reached critical functionality on any released/upstram Linux
versions so it doesn't make
Lars,
On Sat, Mar 16, 2013 at 7:41 AM, Lars-Peter Clausen wrote:
> I think you still need the mutex for serialization, otherwise the requests
> would just cancel each other out. Btw. what happens if you start a conversion
> while another is still in progress? Is it possible to abort a conversion?
-by: Linus Walleij
> Reviewed-by: Doug Anderson
> Tested-by: Doug Anderson
You missed Seungwon's other feedback. Please change the title from
"mmc: dwmmc: let device core setup the default pin configuration" to
"mmc: dw_mmc: let device core setup the default pin config
Thomas,
On Mon, Mar 25, 2013 at 9:56 AM, Doug Anderson wrote:
> Are you planning on doing this? I noticed that Chris pulled your
> sdhci-s3c change in recently but apparently skipped this one since it
> had outstanding comments. Can you address comments and re-send? This
> is blo
Thomas,
On Mon, Mar 11, 2013 at 10:53 AM, Doug Anderson wrote:
> It would be good to address Seungwon Jeon's comments (change prefix to
> dw_mmc and remove setup_bus), but in general this looks good to me,
> so...
Are you planning on doing this? I noticed that Chris pulled
: Doug Anderson
Reviewed-by: Doug Anderson
---
arch/arm/mach-exynos/include/mach/pm-core.h | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/pm-core.h
b/arch/arm/mach-exynos/include/mach/pm-core.h
index 9d8da51e3..7dbbfec 100644
--- a/arch
From: Jonathan Kliegman
For legacy reasons EINT_0 was being forced on for all
exynos systems as a wake interrupt. For boards that need
EINT_0 they should probably enable it with enable_irq_wake
Signed-off-by: Jonathan Kliegman
Signed-off-by: Doug Anderson
Reviewed-by: Doug Anderson
Reviewed
to make suspend/resume reliable on the ARM Chromebook
(exynos5250-snow).
A few more details:
- The first patch is not strictly needed but was a nice cleanup. Our
understanding was that EINT0 was originally turned on for exynos
evt0 silicon and not needed for evt1.
- The second patch is more i
On Fri, Mar 15, 2013 at 2:53 PM, Lars-Peter Clausen wrote:
> What exactly is the spinlock protecting against here? Concurrent runs of
> exynos_adc_isr? This is probably not issue in the first place.
>
> What you want to protect against is that completion is completed between the
> call to INIT_COM
Carpenter
> Cc: Doug Anderson
> Cc: Lars-Peter Clausen
> ---
> Discussion thread for this patch can be found at
> http://www.gossamer-threads.com/lists/linux/kernel/1693284?page=last
>
> drivers/iio/adc/Kconfig |1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Doug And
Hi,
On Thu, Mar 14, 2013 at 7:58 AM, Thomas Abraham
wrote:
>> I can see your point, but as I mentioned earlier there seems to be some
>> timing issue here. By simply doing the reset a few ms earlier (in the first
>> probe, before the driver detects that it needs to defer probing), I already
>>
t; This patch implements the above logic, making EHCI and OHCI work on
> Arndale systems for me.
>
> Signed-off-by: Alexander Graf
> CC: Vivek Gautam
> CC: Jingoo Han
> CC: Alan Stern
> CC: Kukjin Kim
> CC: Felipe Balbi
> CC: Greg Kroah-Hartman
> CC: Doug Anders
Lars,
On Wed, Mar 13, 2013 at 11:40 AM, Lars-Peter Clausen wrote:
>> Yes, but that's a different issue and to be honest I didn't even realize
>> that the patch was trying to fix this as well. In my opinion it's best to
>> split this up into two patches one which fixes the OF dependency. The other
Lars,
On Wed, Mar 13, 2013 at 11:11 AM, Lars-Peter Clausen wrote:
> Agreed. Adding the dependency on OF in Kconfig should be all that is needed.
I think changing the timeout from 'unsigned long' to 'long' is also
legit (to match the actual type returned) and a good idea.
-Doug
--
To unsubscribe
Naveen,
On Tue, Mar 12, 2013 at 9:48 PM, Naveen Krishna Chatradhi
wrote:
> Doug, There was a comment from Lars regarding the match not
> being NULL, if driver depends on CONFIG_OF. So, i've removed
> the NULL check in v2 of this patch.
> https://patchwork.kernel.org/patch/841/
>
> I'm
Alexander,
On Wed, Mar 13, 2013 at 10:45 AM, Alexander Graf wrote:
>
>>> + gpio_free(gpio);
>>
>> Freeing the gpio is a little on the iffy side since you actually care
>> about keeping the value. Perhaps you can change this to
>> devm_gpio_request_one() and avoid the free? I was about to
Alexander,
On Tue, Mar 12, 2013 at 6:09 PM, Alexander Graf wrote:
> - err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, "ehci_vbus_gpio");
> - if (err)
> + /* reset pulls the line down, then up again */
> + err = gpio_request_one(gpio, GPIOF_OUT_INIT_LOW, "ehci_vbus_gpio")
Naveen,
On Wed, Mar 6, 2013 at 7:09 PM, Naveen Krishna Chatradhi
wrote:
> - unsigned intversion;
> + unsigned intversion;
Given that you've changed exynos_adc_get_version() to return an int,
shouldn't this be an int too (not unsigned)?
> -static inline unsig
;https://patchwork.kernel.org/patch/2225151/> on exynos5250-snow
(ARM Chromebook):
Reviewed-by: Doug Anderson
Tested-by: Doug Anderson
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More maj
./devicetree/bindings/spi/spi-samsung.txt|8 +--
> drivers/spi/spi-s3c64xx.c | 66 +--
> 2 files changed, 6 insertions(+), 68 deletions(-)
With <https://patchwork.kernel.org/patch/2225151/> on exynos5250-snow
(ARM Chromebook):
Revi
ration
2224801 New ASoC: samsung: let device core setup the default
pin configuration
2224851 New mmc: dwmmc: let device core setup the default pin
configuration
2225141 New [1/2] ARM: dts: add pin state information in
client nodes for Exynos4 platforms
2225151 New
Linus,
On Thu, Mar 7, 2013 at 6:04 PM, Linus Walleij wrote:
> On Thu, Mar 7, 2013 at 5:13 PM, Doug Anderson wrote:
>
>> ...I think the most important issue at hand is the device tree
>> bindings for pinmux on this device. It sounds like you are in
>> agreement that the
Linus,
+dw_mmc folks and Stephen Warren : for context here, we are discussing
device tree bindings for pinmux for dw_mmc. The issue at hand is
whether they belong under the slot node or under the top-level device
node.
On Wed, Mar 6, 2013 at 11:57 PM, Linus Walleij wrote:
> I don't quite under
Thomas,
On Tue, Mar 5, 2013 at 4:01 PM, Thomas Abraham
wrote:
> So now I have: pinctrl_0 is SPI[46], pinctrl_1 is SPI[45], pinctrl_2
> is SPI[50] and pinctrl_3 is SPI[47]. I am yet to test this and
> confirm. If you feel these are wrong, could you please let me know.
Yes, that matches my finding
Thomas,
On Tue, Mar 5, 2013 at 3:49 PM, Thomas Abraham
wrote:
> Yes, I am currently held up with supporting default pin states at slot
> level. One option that could be considered is to list out the default
> pin states for all slots in the parent node of the slots. So it would
> be something lik
Thomas,
On Mon, Mar 4, 2013 at 6:04 AM, Thomas Abraham
wrote:
>
> Ok. I will repost this patch again with pinctrl_1 and pinctrl_2
> included. I had not included this in the earlier patch since I was not
> sure of the best pin grouping for the camera and c2c interface.
OK, thanks.
>>> --> NOTE:
Tomasz,
Thanks for your response.
On Sat, Mar 2, 2013 at 3:48 AM, Tomasz Figa wrote:
>
> The 4 patches above are already merged in Kgene's for-next-next (for 3.10)
> branch.
Excellent. I see them now. I haven't yet seen them show up in
linux-next (which is where I tend to look first), though
Thomas and Tomasz,
I'm trying to get my head wrapped around the state of pinctrl for
exynos5250. I see various patches that have floated around at times
but it doesn't look like anything has landed. It would be really nice
to get this resolved since I think it blocks getting eint support
landed
The commit: "i2c-core: dt: Pick i2c bus number from i2c alias if
present" adds support for automatically picking the bus number based
on the alias ID. Remove the now unnecessary code from i2c-pxa that
did the same thing.
Signed-off-by: Doug Anderson
---
Changes in v4: None
Changes i
{
i2c0 = &i2c_0;
i2c1 = &i2c_1;
};
Signed-off-by: Doug Anderson
---
Changes in v4:
- Rebased atop the removal of MAX_IDR_MASK.
Changes in v3:
- Addressed Wolfram's feedback; rebased atop idr-cleanup series.
Changes in v2: None
drivers/i2c/i2
corgi_defconfig), since I don't
have access to a board that uses this driver.
Doug Anderson (2):
i2c-core: dt: Pick i2c bus number from i2c alias if present
i2c: pxa: Use i2c-core to get bus number now
drivers/i2c/busses/i2c-pxa.c | 20 --
dri
Wolfram,
On Thu, Feb 28, 2013 at 3:25 PM, Wolfram Sang wrote:
>
> Regarding patch 1, I was waiting for the idr changes to hit mainline.
> They are mainline now, but since the removal of MAX_IDR_MASK your patch
> doesn't apply anymore :( Can you rebase and retest, please? I'd like to
> get it into
Wolfram,
On Mon, Feb 11, 2013 at 4:48 PM, Doug Anderson wrote:
> This was suggested by Mark Brown in response to a patch for adding
> this functionality only for the s3c2410 bus:
> https://lkml.org/lkml/2012/11/20/681
>
> I have also modified the i2c-pxa driver to use this ne
ving the combiner code to drivers/irqchip.
>>
>> Reported-by: Doug Anderson
>> Signed-off-by: Rob Herring
>> Cc: Kukjin Kim
>> Cc: Russell King
>> Cc: Thomas Gleixner
>> Cc: linux-samsung-soc@vger.kernel.org
>> ---
>>
>> I thought there
;t make sense with
dynamically (or automatically) allocated IDs.
- Use dev_name(&dev->dev) to register for the IRQ; this matches what
the i2c-s3c2410.c does and handles dynamically allocated IDs.
- This change was only compile-tested (corgi_defconfig), since I don't
have access to a boar
Wolfram,
Thanks for the review. New patch was just sent. :)
On Sun, Feb 10, 2013 at 4:19 AM, Wolfram Sang wrote:
>> +static int i2c_get_number_from_dt(struct i2c_adapter *adap)
>
> i2c_get_id_from_dt()?
Done.
>> + if (!dev->of_node)
>> + return -1;
>
> -ESOMETHING?
Function
The commit: "i2c-core: dt: Pick i2c bus number from i2c alias if
present" adds support for automatically picking the bus number based
on the alias ID. Remove the now unnecessary code from i2c-pxa that
did the same thing.
Signed-off-by: Doug Anderson
---
Changes in v3: None
Changes i
{
i2c0 = &i2c_0;
i2c1 = &i2c_1;
};
Signed-off-by: Doug Anderson
---
Changes in v3:
- Addressed Wolfram's feedback; rebased atop idr-cleanup series.
Changes in v2: None
drivers/i2c/i2c-core.c | 54 +-
1 file changed, 40 inse
Wolfram,
On Sun, Feb 10, 2013 at 10:17 AM, Wolfram Sang wrote:
> On Mon, Feb 04, 2013 at 02:33:15PM +0530, Yuvaraj Kumar C D wrote:
>> This RFC patch is w.r.t multimaster bus arbitration which is already
>> being discussing in the mainline.
>> This patch provides hooks for the i2c multimaster bus
Yavaraj,
On Mon, Feb 4, 2013 at 1:03 AM, Yuvaraj Kumar C D wrote:
>
> This RFC patch is w.r.t multimaster bus arbitration which is already
> being discussing in the mainline.
> This patch provides hooks for the i2c multimaster bus arbitration
> and to have the arbitration parameters.
I may have
Lars,
Thank you for your comments / thoughts...
On Thu, Jan 24, 2013 at 1:54 AM, Lars-Peter Clausen wrote:
> adc: adc@12D1 {
>
> #io-channel-cells = <1>;
> io-channel-output-names = "adc1", "adc2", ...;
>
> ncp15wb473@0 {
> compatible = "ntc,ncp15wb47
Lars,
On Wed, Jan 23, 2013 at 4:52 AM, Lars-Peter Clausen wrote:
>> Few doubts regarding the mappings and child device handling.
>> Kindly, suggest me better methods.
>
> The patch looks mostly good now. As for the mappings, the problem is that we
> currently do not have any device tree bindings
Vivek,
On Mon, Jan 14, 2013 at 12:06 AM, Vivek Gautam
wrote:
>> Is it fine if we don't use macro for SHIFT, earlier code also doesn't use it.
>> Can we just do like this ..
>> #define HOST_CTRL0_FSEL_MASK (0x7 << 16)
>> #define HOST_CTRL0_FSEL_CLKSEL_50M(0x7 <<
Vivek,
Sorry for being so absent from these reviews. I'll try to look over a
few patches today, but please don't hold up anything on account of my
reviews. I'm definitely a bit of an interested bystander in USB land.
;)
In general things look pretty good here. :) One last comment below...
O
{
i2c0 = &i2c_0;
i2c1 = &i2c_1;
};
Signed-off-by: Doug Anderson
Acked-by: Haojian Zhuang
---
Changes in v2: None
drivers/i2c/i2c-core.c | 105 +++-
1 files changed, 77 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b
The commit: "i2c-core: dt: Pick i2c bus number from i2c alias if
present" adds support for automatically picking the bus number based
on the alias ID. Remove the now unnecessary code from i2c-pxa that
did the same thing.
Signed-off-by: Doug Anderson
---
Changes in v2:
- No longer twea
601 - 700 of 757 matches
Mail list logo
