Re: [PATCH v9 3/5] rtc: max77686: Fail to probe if no RTC regmap irqchip is set
Hello Krzysztof, Sorry for the late response, I was on holidays and slowly catching up on email. On 08/28/2014 11:21 AM, Krzysztof Kozlowski wrote: > On pon, 2014-08-18 at 10:34 +0200, Javier Martinez Canillas wrote: >> The max77686 mfd driver adds a regmap IRQ chip which creates an >> IRQ domain that is used to map the virtual RTC alarm1 interrupt. >> >> The RTC driver assumes that this will always be true since the >> PMIC IRQ is a required property according to the max77686 DT >> binding doc. If an "interrupts" property is not defined for a >> max77686 PMIC, then the mfd probe function will fail and the >> RTC platform driver will never be probed. But even when it is >> not possible to probe the rtc-max77686 driver without a regmap >> IRQ chip, it's better to explicitly check if the IRQ chip data >> is not NULL and gracefully fail instead of getting an OOPS. > > The OOPS was possible only with Bartlomiej's patch because he changed > the MFD driver probe function to skip IRQ setup on lack of interrupts. > In current state the OOPS should not happen so mentioning OOPS in commit > message may be misleading. Maybe just don't put the OOPS here? > > Anyway the patch looks good and a check for non-null > regmap_irq_chip_data is still a valid precaution so: > Yes I know but as you said the check for non-null is still a valid precaution (albeit maybe paranoid) just in case someone find that not having the IRQ hooked makes sense in a design and changes the mfd driver in the future. > Reviewed-by: Krzysztof Kozlowski > > Best regards, > Krzysztof > > Best regards, Javier -- 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 v9 0/5] Add Maxim 77802 RTC support
Hello Alessandro, On Mon, Aug 18, 2014 at 10:34 AM, Javier Martinez Canillas wrote: > This series add support for the Real Time clock present in > the Maxim 77802 Power Managment IC. Previously, the series > was part of a bigger one [0] that aimed to add support for > all the devices in the max77802 PMIC. But now the max77802 > dependencies were already merged for 3.17 so the series can > be split and each driver can go through the relevant tree. > > While working on the max77802 rtc support a lot of feedback > was given and the issues pointed out also apply to a driver > for a similar PMIC RTC (max77686). So patches 01/05 to 04/05 > in the series are cleanups for the max77686 driver and patch > 05/05 adds the support for the max77802 RTC. > > I kept the version numbering from the old series so this is > version 9 although there were no changes on the max77802 rtc > driver since v6 of the old series, only patches 03 and 04 were > added on this version which are cleanups for the max77686 rtc. > > The series were tested on an Exynos5250 Snow (max77686) and > Exynos5420 Peach Pit (max77802) machines and applies cleanly > to both 3.17-rc1 and today's linux-next (20140818). > This series was first posted for 3.17 and you said that it was OK if it gets merged through the MFD tree but you didn't ack the set so it missed 3.17. The max77802 mfd driver dependency made it for 3.17 so that's why I re-posted it for 3.18 about a month ago but got no feedback so far... Since we are in 3.17-rc4 already, I'm afraid that this series may miss 3.18 again. Other people show their interest in the series since it has been reviewed and tested by many folks so it should be safe to merge them. Is there anything else you need from me to pick the series? Thanks a lot and best regards, Javier -- 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 v9 0/6] Add Maxim 77802 clocks support
Hello Mike, On Mon, Aug 18, 2014 at 10:32 AM, Javier Martinez Canillas wrote: > This series add support for the clocks present in the Maxim > 77802 Power Managment IC. Previously, the series was part > of a bigger one [0] that aimed to add support for all the > devices in the max77802 PMIC. But now the Maxim 77802 PMIC > dependencies were already merged for 3.17 so the series can > be split and each driver can go through the relevant tree. > This series was first posted for 3.17 and you acked the whole set but it missed 3.17 because had as a dependency some changes in the max77802 mfd driver. Those dependencies made for 3.17 and that's why I re-posted it for 3.18 about a month ago. Since we are in 3.17-rc4 already, I'm afraid that this series may miss 3.18 again, is there anything else you need from me to pick this series? It will obviously conflict with Tomeu's "Per-user clock constraints" series [0] so if you want I can rebase it on top of your clk-next-tomeu-kirkwood-v2 branch [1]. Thanks a lot and best regards, Javier [0]: https://lkml.org/lkml/2014/9/1/466 [1]: https://git.linaro.org/people/mike.turquette/linux.git/shortlog/refs/heads/clk-next-tomeu-kirkwood-v2 -- 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: Unable to boot mainline on snow chromebook since 3.15
Hello Doug, On 09/08/2014 06:36 AM, Doug Anderson wrote: > > One (ugly?) solution would be to add a feature to your bootloader to > modify the device tree to mark regulators as "always-on". Since the > booloader gets to touch the device tree and the bootloader is involved > in communicating into about SimpleFB, it kinda makes sense. > I can't say I like to mark the regulators as always-on on the DT and that's why I copied the patch in the response instead of posting it as a proper patch but I think relying in the bootloaders to modify the DT is not better. IMHO U-boot should only modify the strictly necessary like the /chosen branch even though lately I've seen some attempts in the OMAP community to (ab)use U-Boot's fdt command to mangle the DT before passing to the kernel in order to support different Beagle Bone Black capes. Best regards, Javier -- 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: Unable to boot mainline on snow chromebook since 3.15
Hi, On Sun, Sep 7, 2014 at 8:52 AM, Tomasz Figa wrote: > Now with regulators this is pretty straightforward, but with clocks I > believe it's an open issue. AFAIR we've discussed this on MLs some time > ago (at least I remember Doug commenting on that topic) and kind of > concluded that SoC clock drivers could include lists of clocks to be > enabled at boot-up (as a HACK to enable things like simplefb until > proper support for respective features are added). I think my old problem was with earlyprintk and a core clock getting disabled. See (44ff025 clk: exynos5420: Remove aclk66_peric from the clock tree description). I think I've seen others solve the same problem with the concept of "critical clocks". I agree that regulator and clock frameworks allow very different "hacks". ;) -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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to boot mainline on snow chromebook since 3.15
Hi, On Sun, Sep 7, 2014 at 8:52 AM, Tomasz Figa wrote: > So I believe we've got a process issue here. If you don't have normal > support for display hardware, but you want to keep the display > operational thanks to bootloader already initializing it, you should not > add anything to the kernel which breaks it, until full support comes in. > > This means that respective regulators should be either always-on or not > listed at all (I'd favor the former) and respective clocks either > somehow enabled at boot-up or completely ignored, including all their > parents capable of being gated. It seems slightly broken to hack the device tree in this way. I'll be the first to admit that I often list regulators as "always-on" during bringup when not everything is done, and I guess it's not that different. ...but given everything going on upstream (and people working on Suspend/Resume, DRM, etc) it seems like it might be a bit of a pain. ...but if that's what everyone agrees on, I won't disagree too strongly. One (ugly?) solution would be to add a feature to your bootloader to modify the device tree to mark regulators as "always-on". Since the booloader gets to touch the device tree and the bootloader is involved in communicating into about SimpleFB, it kinda makes sense. -- 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 v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
On Fri, Sep 5, 2014 at 11:26 PM, Felipe Balbi wrote: > On Thu, Sep 04, 2014 at 12:01:19PM +0530, Vivek Gautam wrote: >> > Don't we have phy_power_on() >> > for that ? It looks like you could just as well do this from >> > phy_power_on() ? >> >> No, unfortunately keeping these calibration settings in phy_power_on() >> doesn't help, since we need to do this after XHCI reset has happened. > > teach xHCI about PHYs ? sorry i couldn't understand you here. Aren't we trying to do the same with Heikki's patch about dwc3 : [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci and the 2nd patch in this series : [PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds Is there something else that is expected ? -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- 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: Unable to boot mainline on snow chromebook since 3.15
Hello Tomasz, On 09/07/2014 06:19 PM, Tomasz Figa wrote: > On 07.09.2014 18:12, Javier Martinez Canillas wrote: >> Clocks is not an issue at least on this machine since the bootloader already >> passes the clk_ignore_unused parameter to the kernel command line so in that >> sense there isn't a regression comparing with older kernels. If possible I >> would prefer to leave this way instead of adding quirks to the clock driver, >> specially since there are proposed patches to have the display working using >> the Exynos DRM driver on this machine. > > Well, clk_ignore_unused seems a bit too coarse grained to me. Also > forcing the user to add it in his bootloader (or any other way) is not > really the best practice IMHO. > Fair enough. > At least for next 3.17-rc I'd suggest fixing this up in respective clock > driver and dropping the hack only after Exynos DRM patches are merged > and confirmed working. > Ok, I'll prepare a patch to add the CLK_IGNORE_UNUSED flag to the needed clocks in drivers/clk/samsung/clk-exynos5250.c. That will be a more fine-grained solution since the clk_ignore_unused kernel parameter won't be needed. > Best regards, > Tomasz > Best regards, Javier -- 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: Unable to boot mainline on snow chromebook since 3.15
On 07.09.2014 18:12, Javier Martinez Canillas wrote: > Hello Tomasz, > > On 09/07/2014 05:52 PM, Tomasz Figa wrote: >> >> So I believe we've got a process issue here. If you don't have normal >> support for display hardware, but you want to keep the display >> operational thanks to bootloader already initializing it, you should not >> add anything to the kernel which breaks it, until full support comes in. >> >> This means that respective regulators should be either always-on or not >> listed at all (I'd favor the former) > > So that means that do you think that the workaround patch I shared on the > previous email could be considered as a correct solution? In that case I can > post it as a proper patch. Right. > >> somehow enabled at boot-up or completely ignored, including all their >> parents capable of being gated. >> > > AFAIU from the thread I mentioned before, Nvidia folks proposed the same to > fix the simplefb issue on sunxi, to avoid the clocks in question being turned > off at boot by modifying the sunxi clock driver. OK. > >> Now with regulators this is pretty straightforward, but with clocks I >> believe it's an open issue. AFAIR we've discussed this on MLs some time >> ago (at least I remember Doug commenting on that topic) and kind of >> concluded that SoC clock drivers could include lists of clocks to be >> enabled at boot-up (as a HACK to enable things like simplefb until >> proper support for respective features are added). >> >> I believe this would be the proper solution for $subject. >> > > Clocks is not an issue at least on this machine since the bootloader already > passes the clk_ignore_unused parameter to the kernel command line so in that > sense there isn't a regression comparing with older kernels. If possible I > would prefer to leave this way instead of adding quirks to the clock driver, > specially since there are proposed patches to have the display working using > the Exynos DRM driver on this machine. Well, clk_ignore_unused seems a bit too coarse grained to me. Also forcing the user to add it in his bootloader (or any other way) is not really the best practice IMHO. At least for next 3.17-rc I'd suggest fixing this up in respective clock driver and dropping the hack only after Exynos DRM patches are merged and confirmed working. Best regards, Tomasz -- 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: Unable to boot mainline on snow chromebook since 3.15
Hello Tomasz, On 09/07/2014 05:52 PM, Tomasz Figa wrote: > > So I believe we've got a process issue here. If you don't have normal > support for display hardware, but you want to keep the display > operational thanks to bootloader already initializing it, you should not > add anything to the kernel which breaks it, until full support comes in. > > This means that respective regulators should be either always-on or not > listed at all (I'd favor the former) So that means that do you think that the workaround patch I shared on the previous email could be considered as a correct solution? In that case I can post it as a proper patch. > somehow enabled at boot-up or completely ignored, including all their > parents capable of being gated. > AFAIU from the thread I mentioned before, Nvidia folks proposed the same to fix the simplefb issue on sunxi, to avoid the clocks in question being turned off at boot by modifying the sunxi clock driver. > Now with regulators this is pretty straightforward, but with clocks I > believe it's an open issue. AFAIR we've discussed this on MLs some time > ago (at least I remember Doug commenting on that topic) and kind of > concluded that SoC clock drivers could include lists of clocks to be > enabled at boot-up (as a HACK to enable things like simplefb until > proper support for respective features are added). > > I believe this would be the proper solution for $subject. > Clocks is not an issue at least on this machine since the bootloader already passes the clk_ignore_unused parameter to the kernel command line so in that sense there isn't a regression comparing with older kernels. If possible I would prefer to leave this way instead of adding quirks to the clock driver, specially since there are proposed patches to have the display working using the Exynos DRM driver on this machine. > Best regards, > Tomasz > Best regards, Javier -- 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: Unable to boot mainline on snow chromebook since 3.15
>>> Have you seen the very long "[PATCH 4/4] simplefb: add clock handling
>>> code" thread [0]?. I wonder if the problem is that the display clocks were
>>> not known to the kernel before 3.15 but now are getting disabled and thus
>>> the simplefb driver not working?
>>>
>>> So probably is worth to try passing clk_ignore_unused as a parameter to
>>> the kernel command line.
>>>
>>> [0]: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06623.html
>>
>
> So my assumptions was correct and the issue is that the kernel disables the
> resources (clocks and regulators) needed to have display working and because
> the simplefb expects the display hardware to have been already initialized by
> the bootloader/firmware, it simply fails.
>
> You didn't face this issue before 3.15 because the default bootargs set by
> nv_uboot-snow already includes the "clk_ignore_unused" parameter and the
> kernel didn't know about the regulators but the later changed with commit:
>
> b16be76 ("ARM: dts: add tps65090 power regulator for exynos5250-snow")
>
> This was included in 3.16, so the mentioned commit is what "broke" your
> workflow since now the kernel is aware of the tps65090 fet1 and fet6
> regulators (used as supply for the the backlight and panel respectively) and
> disables them because nothing uses them from a kernel POV.
So I believe we've got a process issue here. If you don't have normal
support for display hardware, but you want to keep the display
operational thanks to bootloader already initializing it, you should not
add anything to the kernel which breaks it, until full support comes in.
This means that respective regulators should be either always-on or not
listed at all (I'd favor the former) and respective clocks either
somehow enabled at boot-up or completely ignored, including all their
parents capable of being gated.
Now with regulators this is pretty straightforward, but with clocks I
believe it's an open issue. AFAIR we've discussed this on MLs some time
ago (at least I remember Doug commenting on that topic) and kind of
concluded that SoC clock drivers could include lists of clocks to be
enabled at boot-up (as a HACK to enable things like simplefb until
proper support for respective features are added).
I believe this would be the proper solution for $subject.
Best regards,
Tomasz
--
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: Unable to boot mainline on snow chromebook since 3.15
Hello Mark, On 09/07/2014 05:01 PM, Mark Brown wrote: > On Sun, Sep 07, 2014 at 11:06:54AM +0200, Javier Martinez Canillas wrote: > >> But maybe we could add a boot argument similar to "clk_ignore_unused" but for >> regulators? Something like "regulator_ignore_unused" that would prevent the >> regulator core to disable unused regulators? If Mark agrees with that idea >> I'll be glad to propose a patch. > > I'm not all that sympathetic to the idea; we already have quite enough > quality problems with the way people hook up regulators without > providing yet another way for them to hack around things, I'm concerned > it'll just make things more fragile as people require magic command line > arguments to get things working. > I understand your position and I fully agree, I just was thinking aloud. It seems the simplefb approach is somewhat fragile since the driver relies on the bootloader to correctly setup the display hardware and its needed resources (clock, regulators, etc) but also relies on the kernel to not disable those resources even when they are unused from its point of view. So, the best option for Will is to just use Ajay's proposed in-flight Exynos DRM patches or if he really wants to have simplefb working then he can carry the patch I shared to force tps65090 fet1 and fet6 regulators to be always on. Best regards, Javier -- 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: Unable to boot mainline on snow chromebook since 3.15
On Sun, Sep 07, 2014 at 11:06:54AM +0200, Javier Martinez Canillas wrote: > But maybe we could add a boot argument similar to "clk_ignore_unused" but for > regulators? Something like "regulator_ignore_unused" that would prevent the > regulator core to disable unused regulators? If Mark agrees with that idea > I'll be glad to propose a patch. I'm not all that sympathetic to the idea; we already have quite enough quality problems with the way people hook up regulators without providing yet another way for them to hack around things, I'm concerned it'll just make things more fragile as people require magic command line arguments to get things working. signature.asc Description: Digital signature
Re: Unable to boot mainline on snow chromebook since 3.15
[adding Mark Brown to cc since regulators are involved]
Hello Will,
On 09/05/2014 10:25 PM, Doug Anderson wrote:
> Will,
>
> On Fri, Sep 5, 2014 at 5:22 AM, Will Deacon wrote:
>> [Looks like it's not just Rutland that can't spell the address of the
>> mailing list today. Fixed here, so please use this post in any replies].
>>
>> On Fri, Sep 05, 2014 at 12:57:04PM +0100, Will Deacon wrote:
>>> Hi all,
>>>
>>> I'm one of the few, foolish people to try running mainline on my 5250-based
>>> Samsung Chromebook (snow). I can live without wireless, usb3 and video
>>> acceleration, so actually it makes a reasonable development platform for
>>> doing A15-based (micro)-architectural work.
>>>
>>> However, since 3.15 I've not been able to boot *any* mainline kernels on
>>> this board. I did mean to report this earlier, but I have other machines
>>> that can run mainline so this has fallen by the wayside.
>>>
>>> The problems started with 3.16, where simple-fb would fail to initialise
>>> and I lost my display. Note that I don't have a serial console on this
>>> machine (I looked at the PCB and there's no way I can solder one of those
>>> myself :) I bisected the issue at the time, and I could get my display back
>>> by removing some of the new regulator and hdmi properties from the DT. At
>>> that point, I could boot, but DMA didn't initialise for the MMC controller
>>> so I couldn't mount my root filesystem.
>>>
>>> With 3.17-rc3, it seems a lot worse -- I don't get any output after nv-uboot
>>> (i.e. the nv-uboot screen just remains on the display, with the last line
>>> reading "Stashed 20 records").
>>>
>>> I'd usually try to debug this a bit further, but without a console it's
>>> really painful to get anywhere. I've been working with 3.15, but now I'm
>>> having to backport patches when I want to test them, which is more effort
>>> than I can be bothered with.
>>>
>>> Is anybody else running mainline on this device and are these known/fixed
>>> problems?
>
> I've added Javier, who says he'll try to take a look at the problem on
> Monday. He's got a snow and I think he's got a serial console hooked
> up to it (but I don't think he's tried the simplefb workflow).
>
I'm back from holidays with access to the machine again so I was able to look
at your issue.
>
> He also added the following thoughts:
>
>> Have you seen the very long "[PATCH 4/4] simplefb: add clock handling
>> code" thread [0]?. I wonder if the problem is that the display clocks were
>> not known to the kernel before 3.15 but now are getting disabled and thus
>> the simplefb driver not working?
>>
>> So probably is worth to try passing clk_ignore_unused as a parameter to
>> the kernel command line.
>>
>> [0]: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06623.html
>
So my assumptions was correct and the issue is that the kernel disables the
resources (clocks and regulators) needed to have display working and because
the simplefb expects the display hardware to have been already initialized by
the bootloader/firmware, it simply fails.
You didn't face this issue before 3.15 because the default bootargs set by
nv_uboot-snow already includes the "clk_ignore_unused" parameter and the
kernel didn't know about the regulators but the later changed with commit:
b16be76 ("ARM: dts: add tps65090 power regulator for exynos5250-snow")
This was included in 3.16, so the mentioned commit is what "broke" your
workflow since now the kernel is aware of the tps65090 fet1 and fet6
regulators (used as supply for the the backlight and panel respectively) and
disables them because nothing uses them from a kernel POV.
You will have the same issue even with 3.15 if you don't pass the
"clk_ignore_unused" parameter to the kernel command line.
The sunxi folks faced the same issue and tried to solve it by making the
simplefb driver to claim the needed resources thus preventing the kernel to
disable them due not used. But that spawn the very long thread [0] mentioned
above and I've zero interest in joining that discussion...
So, following is a workaround patch [1] that just forces the needed regulators
to be always-on but I don't think this is the proper solution. The right thing
to do IMHO is to use the needed Exynos DRM/KMS patches as Ajay mentioned
before since AFAIU the simplefb is only to have a frame-buffer console working
on platforms where a KMS/DRM driver is not available yet.
But maybe we could add a boot argument similar to "clk_ignore_unused" but for
regulators? Something like "regulator_ignore_unused" that would prevent the
regulator core to disable unused regulators? If Mark agrees with that idea
I'll be glad to propose a patch.
Best regards,
Javier
[0]: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06623.html
[1]:
>From bdbb3bc1d69c10dce58affe74e6b64636f7810b5 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas
Date: Sun, 7 Sep 2014 10:58:29 +0200
Subject: [PATCH 1/1] ARM: dts: prevent exynos5250-snow disp
