Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
On 2015년 07월 22일 11:02, Joonyoung Shim wrote: > On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote: >> Hi, >> >> Today's linux-next (next-20150721) encounters boot failures on Exynos >> Octa (Exynos5422) based boards. The boards hangs. I bisected it to: >> >> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit >> commit d80167b85024982c5f18d0481a5c248100360118 >> Author: Joonyoung Shim >> Date: Thu Jul 2 21:49:39 2015 +0900 >> >> drm/exynos: remove drm_iommu_attach_device_if_possible >> >> Already drm_iommu_attach_device checks whether support iommu internally. >> It should clear channels always regardless iommu support. We didn't know >> because we can detect the problem when iommu is enabled, so we don't >> have to use drm_iommu_attach_device_if_possible and then we can remove >> drm_iommu_attach_device_if_possible and clear_channels function pointer. >> >> Signed-off-by: Joonyoung Shim >> Tested-by: Marek Szyprowski >> Signed-off-by: Inki Dae >> >> :04 04 83379efbf4960f58d680371628ec04387935bd53 >> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers >> >> >> Config: exynos >> Boot log from Odroid XU3-Lite attached. >> >> Any hints or ideas? > > The point that hangs is when accesses fimd register in > fimd_clear_channels function, so i doubt clock setting for fimd. > > It's gone something that hangs after i enable gating for ACLK_200_DISP1 > clock. > > If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it > support. Any ideas? I think bootloader should have enabled ACLK_200_DISP1 clock and also device driver should enable all relevant clocks before the device accesses its own registers. Best way would be that the clock is enabled by common clock framework but it seems there is no anything that the clock framework can do it. So I think what we have to do is to add the clock support to device tree. Other idea? Thanks, Inki Dae > > Thanks. > -- > 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 > -- 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 08/11] MTD: m25p80: Add option to limit SPI transfer size.
On Tue, Jul 21, 2015 at 10:14:11AM +0200, Michal Suchanek wrote: > > Or alternatively we could publish the limitations of the channel using > > capabilities so SPI knows I have a dmaengine channel and it can transfer > > max N > > length transfers so would be able to break rather than guessing it or coding > > in DT. Yes it may come from DT but that should be dmaengine driver rather > > than client driver :) > > > > This can be done by dma_get_slave_caps(chan, &caps) > > > > And we add max_length as one more parameter to existing set > > > > Also all this could be handled in generic SPI-dmaengine layer so that > > individual drivers don't have to code it in > > > > Let me know if this idea is okay, I can push the dmaengine bits... > > It would be ok if there was a fixed limit. However, the limit depends > on SPI slave settings. Presumably for other buses using the dmaengine > the limit would depend on the bus or slave settings as well. I do not > see a sane way of passing this all the way to the dmaengine driver. I don't see why this should be client (SPI) dependent. The max length supported is a dmaengine constraint, typically flowing from max blocks/length it can transfer. Know this limit can allow clients to split transfers. -- ~Vinod -- 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: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote: > Hi, > > Today's linux-next (next-20150721) encounters boot failures on Exynos > Octa (Exynos5422) based boards. The boards hangs. I bisected it to: > > d80167b85024982c5f18d0481a5c248100360118 is the first bad commit > commit d80167b85024982c5f18d0481a5c248100360118 > Author: Joonyoung Shim > Date: Thu Jul 2 21:49:39 2015 +0900 > > drm/exynos: remove drm_iommu_attach_device_if_possible > > Already drm_iommu_attach_device checks whether support iommu internally. > It should clear channels always regardless iommu support. We didn't know > because we can detect the problem when iommu is enabled, so we don't > have to use drm_iommu_attach_device_if_possible and then we can remove > drm_iommu_attach_device_if_possible and clear_channels function pointer. > > Signed-off-by: Joonyoung Shim > Tested-by: Marek Szyprowski > Signed-off-by: Inki Dae > > :04 04 83379efbf4960f58d680371628ec04387935bd53 > da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers > > > Config: exynos > Boot log from Odroid XU3-Lite attached. > > Any hints or ideas? The point that hangs is when accesses fimd register in fimd_clear_channels function, so i doubt clock setting for fimd. It's gone something that hangs after i enable gating for ACLK_200_DISP1 clock. If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it support. Any ideas? Thanks. -- 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 2/3] mfd: Remove MFD_CROS_EC depends on X86 || ARM
On Thu, Jun 25, 2015 at 10:44:28AM +0200, Javier Martinez Canillas wrote: > Hello Lee, > > On 06/25/2015 10:38 AM, Lee Jones wrote: > > On Thu, 25 Jun 2015, Javier Martinez Canillas wrote: > > > >> A dependency on X86 || ARM for MFD_CROS_EC was added to fix the warning: > >> > >> (MFD_CROS_EC) selects CHROME_PLATFORMS which has unmet direct dependencies > >> (X86 || ARM) > >> > >> This happened because CHROME_PLATFORMS had a dependency on X86 || ARM but > >> that dependency was removed since there isn't a reason why the option can > >> not be selected on other architectures. So now the above warning will not > >> happen and the MFD_CROS_EC dependency can be removed since is not needed. > >> > >> Signed-off-by: Javier Martinez Canillas > >> --- > >> > >> drivers/mfd/Kconfig | 1 - > >> 1 file changed, 1 deletion(-) > > > > Applied for v4.3, thanks. > > > > Thanks a lot. > > Olof, > > Could you please ack patch 1/3 so Lee can pick it through the mfd tree? > Since both patches 1/3 and 2/3 are needed to fix the build warning for > !X86 and !ARM architectures. Yep, done. -Olof -- 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 1/3] platform/chrome: Don't make CHROME_PLATFORMS depends on X86 || ARM
On Thu, Jun 25, 2015 at 02:20:42AM +0200, Javier Martinez Canillas wrote: > The Chrome platform support depends on X86 || ARM because there are > only Chromebooks using those architectures. But only some drivers > depend on a given architecture, and the ones that do already have > a dependency on their specific Kconfig symbol entries. > > An option is to also make CHROME_PLATFORMS depends on || COMPILE_TEST > but is more future proof to remove the dependency and let the drivers > be built in all architectures if possible to have more build coverage. > > Signed-off-by: Javier Martinez Canillas Acked-by: Olof Johansson -Olof -- 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 2/3] mfd: Remove MFD_CROS_EC depends on X86 || ARM
On Tue, Jul 21, 2015 at 6:13 PM, Paul Gortmaker wrote: > [Re: [PATCH 2/3] mfd: Remove MFD_CROS_EC depends on X86 || ARM] On 25/06/2015 > (Thu 10:44) Javier Martinez Canillas wrote: > >> Hello Lee, >> >> On 06/25/2015 10:38 AM, Lee Jones wrote: >> > On Thu, 25 Jun 2015, Javier Martinez Canillas wrote: >> > >> >> A dependency on X86 || ARM for MFD_CROS_EC was added to fix the warning: >> >> >> >> (MFD_CROS_EC) selects CHROME_PLATFORMS which has unmet direct >> >> dependencies (X86 || ARM) >> >> >> >> This happened because CHROME_PLATFORMS had a dependency on X86 || ARM but >> >> that dependency was removed since there isn't a reason why the option can >> >> not be selected on other architectures. So now the above warning will not >> >> happen and the MFD_CROS_EC dependency can be removed since is not needed. >> >> >> >> Signed-off-by: Javier Martinez Canillas >> >> --- >> >> >> >> drivers/mfd/Kconfig | 1 - >> >> 1 file changed, 1 deletion(-) >> > >> > Applied for v4.3, thanks. >> > >> >> Thanks a lot. >> >> Olof, >> >> Could you please ack patch 1/3 so Lee can pick it through the mfd tree? >> Since both patches 1/3 and 2/3 are needed to fix the build warning for >> !X86 and !ARM architectures. > > Hi all, > > Wondering if this fell through the cracks. It used to be just a > linux-next issue, but now it is a mainline issue. This _really_ should > be fixed and fed to Linus ASAP. Ideally it should have been fixed before > going to mainline as it was reported in plenty of time ; that is the > whole point of linux-next to fix unanticipated fallout and revise. Yep, agreed. I've been a bit removed from upstream work for the last couple of months (getting back to it now), so I've been bad at following up on this. Acks sent now, Lee, please pick up for 4.2 if you don't mind. -Olof -- 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 2/3] mfd: Remove MFD_CROS_EC depends on X86 || ARM
Hello Paul, On Wed, Jul 22, 2015 at 3:13 AM, Paul Gortmaker wrote: > [Re: [PATCH 2/3] mfd: Remove MFD_CROS_EC depends on X86 || ARM] On 25/06/2015 > (Thu 10:44) Javier Martinez Canillas wrote: > >> Hello Lee, >> >> On 06/25/2015 10:38 AM, Lee Jones wrote: >> > On Thu, 25 Jun 2015, Javier Martinez Canillas wrote: >> > >> >> A dependency on X86 || ARM for MFD_CROS_EC was added to fix the warning: >> >> >> >> (MFD_CROS_EC) selects CHROME_PLATFORMS which has unmet direct >> >> dependencies (X86 || ARM) >> >> >> >> This happened because CHROME_PLATFORMS had a dependency on X86 || ARM but >> >> that dependency was removed since there isn't a reason why the option can >> >> not be selected on other architectures. So now the above warning will not >> >> happen and the MFD_CROS_EC dependency can be removed since is not needed. >> >> >> >> Signed-off-by: Javier Martinez Canillas >> >> --- >> >> >> >> drivers/mfd/Kconfig | 1 - >> >> 1 file changed, 1 deletion(-) >> > >> > Applied for v4.3, thanks. >> > >> >> Thanks a lot. >> >> Olof, >> >> Could you please ack patch 1/3 so Lee can pick it through the mfd tree? >> Since both patches 1/3 and 2/3 are needed to fix the build warning for >> !X86 and !ARM architectures. > > Hi all, > > Wondering if this fell through the cracks. It used to be just a > linux-next issue, but now it is a mainline issue. This _really_ should > be fixed and fed to Linus ASAP. Ideally it should have been fixed before > going to mainline as it was reported in plenty of time ; that is the > whole point of linux-next to fix unanticipated fallout and revise. > Sorry that I didn't follow up on this but I recently changed jobs and was quite busy and travelling. The problem as is explained above in the quoted text is that $subject is not enough to fix the issue, patch 1/3 should also be picked but that is waiting for Olof's ack. I agree that both patches 1/3 and 2/3 have to be sent as an -rc fix since the commit that introduced the issue made it to 4.2. Patch 3/3 can wait for 4.3 which BTW I see that has not been applied either. > -- > paul@builder:~/git/linux-head$ git describe > v4.2-rc3 > paul@builder:~/git/linux-head$ echo $ARCH > sparc64 > paul@builder:~/git/linux-head$ make allyesconfig > scripts/kconfig/conf --allyesconfig Kconfig > warning: (MFD_CROS_EC) selects CHROME_PLATFORMS which has unmet direct > dependencies (X86 || ARM) > # > # configuration written to .config > # > paul@builder:~/git/linux-head$ > -- > > Thanks, > Paul. > -- > 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 2/3] mfd: Remove MFD_CROS_EC depends on X86 || ARM
[Re: [PATCH 2/3] mfd: Remove MFD_CROS_EC depends on X86 || ARM] On 25/06/2015 (Thu 10:44) Javier Martinez Canillas wrote: > Hello Lee, > > On 06/25/2015 10:38 AM, Lee Jones wrote: > > On Thu, 25 Jun 2015, Javier Martinez Canillas wrote: > > > >> A dependency on X86 || ARM for MFD_CROS_EC was added to fix the warning: > >> > >> (MFD_CROS_EC) selects CHROME_PLATFORMS which has unmet direct dependencies > >> (X86 || ARM) > >> > >> This happened because CHROME_PLATFORMS had a dependency on X86 || ARM but > >> that dependency was removed since there isn't a reason why the option can > >> not be selected on other architectures. So now the above warning will not > >> happen and the MFD_CROS_EC dependency can be removed since is not needed. > >> > >> Signed-off-by: Javier Martinez Canillas > >> --- > >> > >> drivers/mfd/Kconfig | 1 - > >> 1 file changed, 1 deletion(-) > > > > Applied for v4.3, thanks. > > > > Thanks a lot. > > Olof, > > Could you please ack patch 1/3 so Lee can pick it through the mfd tree? > Since both patches 1/3 and 2/3 are needed to fix the build warning for > !X86 and !ARM architectures. Hi all, Wondering if this fell through the cracks. It used to be just a linux-next issue, but now it is a mainline issue. This _really_ should be fixed and fed to Linus ASAP. Ideally it should have been fixed before going to mainline as it was reported in plenty of time ; that is the whole point of linux-next to fix unanticipated fallout and revise. -- paul@builder:~/git/linux-head$ git describe v4.2-rc3 paul@builder:~/git/linux-head$ echo $ARCH sparc64 paul@builder:~/git/linux-head$ make allyesconfig scripts/kconfig/conf --allyesconfig Kconfig warning: (MFD_CROS_EC) selects CHROME_PLATFORMS which has unmet direct dependencies (X86 || ARM) # # configuration written to .config # paul@builder:~/git/linux-head$ -- Thanks, Paul. -- > > 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: [GIT PULL] ARM: EXYNOS: mach: Improvements for 4.3
On 21.07.2015 14:21, Krzysztof Kozlowski wrote: > 2015-07-21 14:13 GMT+09:00 Krzysztof Kozlowski : >> 2015-07-21 14:02 GMT+09:00 Kukjin Kim : >>> Krzysztof Kozlowski wrote: Dear Kukjin, Exynos mach-code related improvements. Description along with a tag. You can find them also on the lists with my reviewed-by. Best regards, Krzysztof The following changes since commit 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93: Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2015- 07-05 16:24:54 -0700) are available in the git repository at: https://github.com/krzk/linux.git tags/samsung-mach-4.3 for you to fetch changes up to 70f83b6716ea0e5944071c12ff1716f93a9c2d8d: cpufreq: exynos: remove Exynos5250 specific cpufreq driver support (2015-07-16 10:39:56 +0900) Improvements for Exynos based boards: 1. Switch to generic cpufreq-dt driver for Exynos5250. The old driver is removed. 2. Fix memory leak in cpufreq error path. 3. Cleanups: remove duplicated define with bootloader's sleep magic constant, staticize local function, drop 'owner' from platform driver, fix cast of iomem to ERR_PTR. Bartlomiej Zolnierkiewicz (1): cpufreq: exynos: remove Exynos5250 specific cpufreq driver support Krzysztof Kozlowski (4): ARM: EXYNOS: pmu: Make local function static ARM: EXYNOS: Remove duplicated define of SLEEP_MAGIC ARM: EXYNOS: pmu: Drop owner assignment ARM: EXYNOS: Use IOMEM_ERR_PTR when function returns iomem Shailendra Verma (1): cpufreq: exynos: Fix for memory leak in case SOC name does not match Thomas Abraham (3): clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock ARM: dts: Exynos5250: add CPU OPP and regulator supply property ARM: Exynos: switch to using generic cpufreq driver for Exynos5250 arch/arm/boot/dts/exynos5250-arndale.dts | 4 + arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 + arch/arm/boot/dts/exynos5250-snow.dts | 4 + arch/arm/boot/dts/exynos5250-spring.dts | 4 + arch/arm/boot/dts/exynos5250.dtsi | 22 arch/arm/mach-exynos/common.h | 6 + arch/arm/mach-exynos/exynos.c | 1 + arch/arm/mach-exynos/firmware.c | 2 - arch/arm/mach-exynos/platsmp.c| 2 +- arch/arm/mach-exynos/pmu.c| 3 +- arch/arm/mach-exynos/suspend.c| 4 +- drivers/clk/samsung/clk-exynos5250.c | 31 + drivers/cpufreq/Kconfig.arm | 11 -- drivers/cpufreq/Makefile | 1 - drivers/cpufreq/exynos-cpufreq.c | 9 +- drivers/cpufreq/exynos-cpufreq.h | 17 --- drivers/cpufreq/exynos5250-cpufreq.c | 210 -- include/dt-bindings/clock/exynos5250.h| 1 + 18 files changed, 84 insertions(+), 252 deletions(-) delete mode 100644 drivers/cpufreq/exynos5250-cpufreq.c -- >>> >>> Applied above changes into fixes/non-critical, next/cleanup-samsung, >>> next/dt-samsung and next/cpufreq-clk-samsung according to the change. > > Cc-ed Bartlomiej, > > One issue found: splitting DTS change for Exynos 5250 cpufreq to > separate branch will break bisectability. The commit "ARM: dts: > Exynos5250: add CPU OPP and regulator supply property": > 1. MUST be put after "clk: samsung: exynos5250: add cpu clock > configuration data and instantiate cpu clock" to prevent build > failures, > 2. should be put before "ARM: Exynos: switch to using generic cpufreq > driver for Exynos5250" to prevent lost cpufreq functionality. > > Doing otherwise would lose bisectability which is really unfortunate > when you can simply avoid it. This should remain in the same branch - > next/cpufreq-clk-samsung. Dear Kukjin, Nothing changed since yesterday... so let me point this in a more clear way. The way you divided the patchset causes build errors: -- HEAD is now at 565872a601c4... ARM: dts: add CPU OPP and regulator supply property for exynos5250 ERROR: Failed build: -A arm -c exynos on 565872a601c4d91a75b917b1fb40ff27ad7ebb08 LOGS: Error: ../arch/arm/boot/dts/exynos5250.dtsi:65.21-22 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [arch/arm/boot/dts/exynos5250-arndale.dtb] Error 1 make[1]: *** [dtbs] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [sub-make] Error 2 -- This breaks bisectability without any special valid reason. Best regards, Krzysztof -- To unsubscr
Re: [PATCH v2] clk: exynos4: Fix wrong clock for Exynos4x12 ADC
On 22.07.2015 07:42, Stephen Boyd wrote:
> On 06/12, Krzysztof Kozlowski wrote:
>> The TSADC gate clock was used in Exynos4x12 DTSI for exynos-adc driver.
>> However TSADC is present only on Exynos4210 so on Trats2 board (with
>> Exynos4412 SoC) the exynos-adc driver could not be probed:
>>ERROR: could not get clock /adc@126C:adc(0)
>>exynos-adc 126c.adc: failed getting clock, err = -2
>>exynos-adc: probe of 126c.adc failed with error -2
>>
>> Instead on Exynos4x12 SoCs the main clock used by Analog to Digital
>> Converter is located in different register and it is named in datasheet
>> as PCLK_ADC. Regardless of the name the purpose of this PCLK_ADC clock
>> is the same as purpose of TSADC from Exynos4210.
>>
>> The patch adds gate clock for Exynos4x12 using the proper register so
>> backward compatibility is preserved. This fixes the probe of exynos-adc
>> driver on Exynos4x12 boards and allows accessing sensors connected to it
>> on Trats2 board (ntc,ncp15wb473 AP and battery thermistors).
>>
>> Signed-off-by: Krzysztof Kozlowski
>> Cc:
>> Fixes: c63c57433003 ("ARM: dts: Add ADC's dt data to read raw data for
>> exynos4x12")
>> Link: https://lkml.org/lkml/2015/6/11/85
>>
>
> Did you want clk maintainers to apply this? The To: list is not
> helping so I'm not sure what's going on and it seems to have
> slipped through the cracks.
Thank you for being proactive! I appreciate this.
Some time ago Sylwester replied that he took care about this patch so I
think this will go through Samsung clock tree.
Sylwester, are you planning to send this as fix for 4.2-rc?
Best regards,
Krzysztof
--
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] clk: exynos4: Fix wrong clock for Exynos4x12 ADC
On 06/12, Krzysztof Kozlowski wrote:
> The TSADC gate clock was used in Exynos4x12 DTSI for exynos-adc driver.
> However TSADC is present only on Exynos4210 so on Trats2 board (with
> Exynos4412 SoC) the exynos-adc driver could not be probed:
>ERROR: could not get clock /adc@126C:adc(0)
>exynos-adc 126c.adc: failed getting clock, err = -2
>exynos-adc: probe of 126c.adc failed with error -2
>
> Instead on Exynos4x12 SoCs the main clock used by Analog to Digital
> Converter is located in different register and it is named in datasheet
> as PCLK_ADC. Regardless of the name the purpose of this PCLK_ADC clock
> is the same as purpose of TSADC from Exynos4210.
>
> The patch adds gate clock for Exynos4x12 using the proper register so
> backward compatibility is preserved. This fixes the probe of exynos-adc
> driver on Exynos4x12 boards and allows accessing sensors connected to it
> on Trats2 board (ntc,ncp15wb473 AP and battery thermistors).
>
> Signed-off-by: Krzysztof Kozlowski
> Cc:
> Fixes: c63c57433003 ("ARM: dts: Add ADC's dt data to read raw data for
> exynos4x12")
> Link: https://lkml.org/lkml/2015/6/11/85
>
Did you want clk maintainers to apply this? The To: list is not
helping so I'm not sure what's going on and it seems to have
slipped through the cracks.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: [GIT PULL] Samsung 1st fixes for v4.2
Hi Kukjin, On Tue, Jul 21, 2015 at 12:40:04PM +0900, Kukjin Kim wrote: > Hi, > > Please pull samsung fixes for v4.2. > > Thanks, > Kukjin > > The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754: > > Linux 4.2-rc1 (2015-07-05 11:01:52 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > tags/samsung-fixes-1 > > for you to fetch changes up to 300bde79f3d86b1af6fcde7b7b2439ecffccbff4: > > ARM: dts: add CPU OPP and regulator supply property for exynos4210 > (2015-07-21 12:32:29 +0900) Was there a reason you rebased Krzystztof's branch? The contents is identical. In cases like those, feel free to just forward the pull request to us and we can do it directly. If you have more patches you want to add into the same fixes branch then you can just merge his in and apply yours on top. That's for example how Tony Lindgren tends to handle OMAP -- he'll forward a pull request from Paul Walmsley if that's the only contents he has. Anyway, merged. -Olof -- 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 9/9] drm/exynos: Convert g2d_userptr_get_dma_addr() to use get_vaddr_frames()
On Sat 18-07-15 12:14:12, Inki Dae wrote:
> On 2015년 07월 17일 19:31, Hans Verkuil wrote:
> > On 07/17/2015 12:29 PM, Inki Dae wrote:
> >> On 2015년 07월 17일 19:20, Hans Verkuil wrote:
> >>> On 07/13/2015 04:55 PM, Jan Kara wrote:
> From: Jan Kara
>
> Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_frames().
> This removes the knowledge about vmas and mmap_sem locking from exynos
> driver. Also it fixes a problem that the function has been mapping user
> provided address without holding mmap_sem.
> >>>
> >>> I'd like to see an Ack from one of the exynos drm driver maintainers
> >>> before
> >>> I merge this.
> >>>
> >>> Inki, Marek?
> >>
> >> I already gave Ack but it seems that Jan missed it while updating.
> >>
> >> Anyway,
> >> Acked-by: Inki Dae
> >
> > Thanks!
>
> Oops, sorry. This patch would incur a build warning. Below is my comment.
>
> @@ -456,65 +455,38 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
> drm_device *drm_dev,
> return ERR_PTR(-ENOMEM);
>
> atomic_set(&g2d_userptr->refcount, 1);
> +g2d_userptr->size = size;
>
> start = userptr & PAGE_MASK;
> offset = userptr & ~PAGE_MASK;
> end = PAGE_ALIGN(userptr + size);
> npages = (end - start) >> PAGE_SHIFT;
> -g2d_userptr->npages = npages;
> -
> -pages = drm_calloc_large(npages, sizeof(struct page *));
> -if (!pages) {
> -DRM_ERROR("failed to allocate pages.\n");
> -ret = -ENOMEM;
> +g2d_userptr->vec = frame_vector_create(npages);
> +if (!g2d_userptr->vec)
>
> You would need ret = -EFAULT here. And below is a patch posted already,
> http://www.spinics.net/lists/dri-devel/msg85321.html
The error should IMHO be -ENOMEM because frame_vector_create() fails only
if we fail to allocate the structure. Attached is the updated version of
the patch. Hans, can you please pick this one?
> ps. please, ignore the codes related to build error in the patch.
>
> With the change, Acked-by: Inki Dae
Thanks and sorry for making so many stupid mistakes in the Exynos driver.
Honza
--
Jan Kara
SUSE Labs, CR
>From e1ce3781eb0a3ffe045055f4145bc60ee7b2a6b5 Mon Sep 17 00:00:00 2001
From: Jan Kara
Date: Wed, 4 Dec 2013 14:41:22 +0100
Subject: [PATCH 9/9] drm/exynos: Convert g2d_userptr_get_dma_addr() to use
get_vaddr_frames()
Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_frames().
This removes the knowledge about vmas and mmap_sem locking from exynos
driver. Also it fixes a problem that the function has been mapping user
provided address without holding mmap_sem.
Acked-by: Inki Dae
Signed-off-by: Jan Kara
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 89 ++
drivers/gpu/drm/exynos/exynos_drm_gem.c | 97 -
3 files changed, 30 insertions(+), 157 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 43003c4ad80b..b364562dc6c1 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -77,6 +77,7 @@ config DRM_EXYNOS_VIDI
config DRM_EXYNOS_G2D
bool "Exynos DRM G2D"
depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_G2D
+ select FRAME_VECTOR
help
Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 81a250830808..7584834a53c9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -190,10 +190,8 @@ struct g2d_cmdlist_userptr {
dma_addr_t dma_addr;
unsigned long userptr;
unsigned long size;
- struct page **pages;
- unsigned int npages;
+ struct frame_vector *vec;
struct sg_table *sgt;
- struct vm_area_struct *vma;
atomic_t refcount;
bool in_pool;
bool out_of_list;
@@ -363,6 +361,7 @@ static void g2d_userptr_put_dma_addr(struct drm_device *drm_dev,
{
struct g2d_cmdlist_userptr *g2d_userptr =
(struct g2d_cmdlist_userptr *)obj;
+ struct page **pages;
if (!obj)
return;
@@ -382,19 +381,21 @@ out:
exynos_gem_unmap_sgt_from_dma(drm_dev, g2d_userptr->sgt,
DMA_BIDIRECTIONAL);
- exynos_gem_put_pages_to_userptr(g2d_userptr->pages,
- g2d_userptr->npages,
- g2d_userptr->vma);
+ pages = frame_vector_pages(g2d_userptr->vec);
+ if (!IS_ERR(pages)) {
+ int i;
- exynos_gem_put_vma(g2d_userptr->vma);
+ for (i = 0; i < frame_vector_count(g2d_userptr->vec); i++)
+ set_page_dirty_lock(pages[i]);
+ }
+ put_vaddr_frames(g2d_userptr->vec);
+ frame_vector_destroy(g2d_userptr->vec);
if (!g2d_userptr->out_of_list)
list_del_init(&g2d_userptr->list);
sg_free_table(g2d_userptr->sgt);
kfree(g2d_userptr->sgt);
-
-
RE: [PATCH v2] thermal: consistently use int for temperatures
> -Original Message- > From: Punit Agrawal [mailto:punit.agra...@arm.com] > Sent: Tuesday, July 21, 2015 6:52 PM > To: Sascha Hauer > Cc: linux...@vger.kernel.org; Zhang, Rui; Eduardo Valentin; linux- > ker...@vger.kernel.org; Jean Delvare; Peter Feuerer; Heiko Stuebner; > Lukasz Majewski; Stephen Warren; Thierry Reding; linux- > a...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-o...@vger.kernel.org; linux-samsung- > s...@vger.kernel.org; Guenter Roeck; Rafael J. Wysocki; Maxime Ripard; > Darren Hart; lm-sens...@lm-sensors.org > Subject: Re: [PATCH v2] thermal: consistently use int for temperatures > Importance: High > > Hi Sascha, > > Sascha Hauer writes: > > > The thermal code uses int, long and unsigned long for temperatures in > > different places. > > > > Using an unsigned type limits the thermal framework to positive > > temperatures without need. Also several drivers currently will report > > temperatures near UINT_MAX for temperatures below 0°C. This will > > probably immediately shut the machine down due to overtemperature if > > started below 0°C. > > > > 'long' is 64bit on several architectures. This is not needed since > > INT_MAX °mC is above the melting point of all known materials. > > > > Consistently use a plain 'int' for temperatures throughout the thermal > > code and the drivers. This only changes the places in the drivers > > where the temperature is passed around as pointer, when drivers > > internally use another type this is not changed. > > > > Signed-off-by: Sascha Hauer > > Acked-by: Geert Uytterhoeven > > Reviewed-by: Jean Delvare > > Reviewed-by: Lukasz Majewski > > Reviewed-by: Darren Hart > > Reviewed-by: Heiko Stuebner > > Reviewed-by: Peter Feuerer > > Cc: Punit Agrawal > > The changes below look good. > > For the power_allocator governor and corresponding trace events, > > Reviewed-by: Punit Agrawal > > Thanks > > > Cc: Zhang Rui > > Cc: Eduardo Valentin > > Cc: linux...@vger.kernel.org > > Cc: linux-ker...@vger.kernel.org > > Cc: Jean Delvare > > Cc: Peter Feuerer > > Cc: Heiko Stuebner > > Cc: Lukasz Majewski > > Cc: Stephen Warren > > Cc: Thierry Reding > > Cc: linux-a...@vger.kernel.org > > Cc: platform-driver-...@vger.kernel.org > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: linux-o...@vger.kernel.org > > Cc: linux-samsung-soc@vger.kernel.org > > Cc: Guenter Roeck > > Cc: Rafael J. Wysocki > > Cc: Maxime Ripard > > Cc: Darren Hart > > Cc: lm-sens...@lm-sensors.org > > --- > > Patch applied. Thanks, rui > > changes since v1: > > - Add missing pieces for power_allocator driver > > > > drivers/acpi/thermal.c | 12 +- > > drivers/hwmon/lm75.c | 2 +- > > drivers/hwmon/ntc_thermistor.c | 2 +- > > drivers/hwmon/tmp102.c | 2 +- > > drivers/input/touchscreen/sun4i-ts.c | 8 +++ > > drivers/platform/x86/acerhdf.c | 9 > > drivers/platform/x86/intel_mid_thermal.c | 9 > > drivers/power/power_supply_core.c | 2 +- > > drivers/thermal/armada_thermal.c | 2 +- > > drivers/thermal/db8500_thermal.c | 7 +++--- > > drivers/thermal/dove_thermal.c | 2 +- > > drivers/thermal/fair_share.c | 2 +- > > drivers/thermal/gov_bang_bang.c| 5 ++-- > > drivers/thermal/hisi_thermal.c | 4 ++-- > > drivers/thermal/imx_thermal.c | 27 > > +++--- > > drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +- > > .../thermal/int340x_thermal/int340x_thermal_zone.c | 10 > > .../thermal/int340x_thermal/int340x_thermal_zone.h | 8 +++ > > .../int340x_thermal/processor_thermal_device.c | 4 ++-- > > drivers/thermal/intel_quark_dts_thermal.c | 13 +-- > > drivers/thermal/intel_soc_dts_iosf.c | 8 +++ > > drivers/thermal/kirkwood_thermal.c | 2 +- > > drivers/thermal/of-thermal.c | 14 +-- > > drivers/thermal/power_allocator.c | 16 ++--- > > drivers/thermal/qcom-spmi-temp-alarm.c | 2 +- > > drivers/thermal/rcar_thermal.c | 7 +++--- > > drivers/thermal/rockchip_thermal.c | 10 > > drivers/thermal/samsung/exynos_tmu.c | 23 +- > > drivers/thermal/spear_thermal.c| 2 +- > > drivers/thermal/st/st_thermal.c| 5 ++-- > > drivers/thermal/step_wise.c| 4 ++-- > > drivers/thermal/tegra_soctherm.c | 4 ++-- > > drivers/thermal/thermal_core.c | 26 > > ++--- > > drivers/thermal/thermal_hwmon.c| 10 +
Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
Hi, Today's linux-next (next-20150721) encounters boot failures on Exynos Octa (Exynos5422) based boards. The boards hangs. I bisected it to: d80167b85024982c5f18d0481a5c248100360118 is the first bad commit commit d80167b85024982c5f18d0481a5c248100360118 Author: Joonyoung Shim Date: Thu Jul 2 21:49:39 2015 +0900 drm/exynos: remove drm_iommu_attach_device_if_possible Already drm_iommu_attach_device checks whether support iommu internally. It should clear channels always regardless iommu support. We didn't know because we can detect the problem when iommu is enabled, so we don't have to use drm_iommu_attach_device_if_possible and then we can remove drm_iommu_attach_device_if_possible and clear_channels function pointer. Signed-off-by: Joonyoung Shim Tested-by: Marek Szyprowski Signed-off-by: Inki Dae :04 04 83379efbf4960f58d680371628ec04387935bd53 da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers Config: exynos Boot log from Odroid XU3-Lite attached. Any hints or ideas? Best regards, Krzysztof Starting kernel ... [0.00] Booting Linux on physical CPU 0x100 [0.00] Linux version 4.2.0-rc2-00314-gd80167b85024 (kozik@kozik-lap) (gcc version 4.7.4 (Ubuntu/Linaro 4.7.4-2ubuntu1) ) #766 SMP PREEMPT Tue Jul 21 22:12:16 KST 2015 [0.00] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: Hardkernel Odroid XU3 Lite [0.00] cma: Reserved 64 MiB at 0xba80 [0.00] Memory policy: Data cache writealloc [0.00] Samsung CPU ID: 0xe5422001 [0.00] Running under secure firmware. [0.00] PERCPU: Embedded 11 pages/cpu @ee77f000 s15040 r8192 d21824 u45056 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 513040 [0.00] Kernel command line: console=tty1 console=ttySAC2,115200n8 root=/dev/mmcblk0p1 rootwait rw smsc95xx.macaddr=00:1e:06:61:7a:93 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1957712K/2058240K available (6176K kernel code, 314K rwdata, 2232K rodata, 412K init, 8223K bss, 34992K reserved, 65536K cma-reserved, 1230848K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc083e2e8 (8409 kB) [0.00] .init : 0xc083f000 - 0xc08a6000 ( 412 kB) [0.00] .data : 0xc08a6000 - 0xc08f4b68 ( 315 kB) [0.00].bss : 0xc08f7000 - 0xc10fef60 (8224 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [0.00] Running RCU self tests [0.00] Preemptible hierarchical RCU implementation. [0.00] RCU lockdep checking is enabled. [0.00] Additional per-CPU info printed with stalls. [0.00] Build-time adjustment of leaf fanout to 32. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] GIC physical location is 0x10481000 [0.00] L2C: failed to init: -19 [0.00] Switching to timer-based delay loop, resolution 41ns [0.00] clocksource: mct-frc: mask: 0x max_cycles: 0x, max_idle_ns: 79635851949 ns [0.08] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns [0.000986] Console: colour dummy device 80x30 [0.003960] console [tty1] enabled [0.004000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.004063] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.004102] ... MAX_LOCK_DEPTH: 48 [0.004140] ... MAX_LOCKDEP_KEYS:8191 [0.004179] ... CLASSHASH_SIZE: 4096 [0.004218] ... MAX_LOCKDEP_ENTRIES: 32768 [0.004258] ... MAX_LOCKDEP_CHAINS: 65536 [0.004297] ... CHAINHASH_SIZE: 32768 [0.004336] memory used by lock dependency info: 5167 kB [0.004379] per task-struct memory footprint: 1536 bytes [0.004471] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=12) [0.004557] pid_max: default: 32768 minimum: 301 [0.005348] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.005410] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.008857] CPU: Testing write buffer coherency: ok [0.010644] CPU0: update cpu_capacity 448 [0.010702] CPU0: thread -1
Re: [PATCHv7 14/15] cec: s5p-cec: Add s5p-cec driver
Hello,
On 2015-07-16 15:09, Hans Verkuil wrote:
Marek, Kamil,
On 06/29/15 12:14, Hans Verkuil wrote:
From: Kamil Debski
Add CEC interface driver present in the Samsung Exynos range of
SoCs.
The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
diff --git a/drivers/media/platform/s5p-cec/s5p_cec.c
b/drivers/media/platform/s5p-cec/s5p_cec.c
new file mode 100644
index 000..0f16d00
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/s5p_cec.c
@@ -0,0 +1,283 @@
+/* drivers/media/platform/s5p-cec/s5p_cec.c
+ *
+ * Samsung S5P CEC driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is based on the "cec interface driver for exynos soc" by
+ * SangPil Moon.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "exynos_hdmi_cec.h"
+#include "regs-cec.h"
+#include "s5p_cec.h"
+
+#define CEC_NAME "s5p-cec"
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-2)");
+
+static int s5p_cec_enable(struct cec_adapter *adap, bool enable)
+{
+ struct s5p_cec_dev *cec = container_of(adap, struct s5p_cec_dev, adap);
+ int ret;
+
+ if (enable) {
+ ret = pm_runtime_get_sync(cec->dev);
+
+ adap->phys_addr = 0x100b;
This is a bogus physical address. The actual physical address has to be derived
from the EDID that is read by the HDMI transmitter.
I think in the case of this driver it will have to be userspace that assigns
the physical address after reading the EDID from drm/kms?
How did you test this, Kamil?
If I remember correctly, physical address has been derived from EDID in the
userspace (it is available in /sys/class/drm/*) and passed to s5p-cec
driver by
appropriate ioctl.
I don't know what is the reason for the above 'adap->phys_addr = 0x100b'
assignment.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
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] thermal: consistently use int for temperatures
Hi Sascha,
Sascha Hauer writes:
> The thermal code uses int, long and unsigned long for temperatures
> in different places.
>
> Using an unsigned type limits the thermal framework to positive
> temperatures without need. Also several drivers currently will report
> temperatures near UINT_MAX for temperatures below 0°C. This will probably
> immediately shut the machine down due to overtemperature if started below
> 0°C.
>
> 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
> is above the melting point of all known materials.
>
> Consistently use a plain 'int' for temperatures throughout the thermal code
> and
> the drivers. This only changes the places in the drivers where the temperature
> is passed around as pointer, when drivers internally use another type this is
> not changed.
>
> Signed-off-by: Sascha Hauer
> Acked-by: Geert Uytterhoeven
> Reviewed-by: Jean Delvare
> Reviewed-by: Lukasz Majewski
> Reviewed-by: Darren Hart
> Reviewed-by: Heiko Stuebner
> Reviewed-by: Peter Feuerer
> Cc: Punit Agrawal
The changes below look good.
For the power_allocator governor and corresponding trace events,
Reviewed-by: Punit Agrawal
Thanks
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Cc: linux...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: Jean Delvare
> Cc: Peter Feuerer
> Cc: Heiko Stuebner
> Cc: Lukasz Majewski
> Cc: Stephen Warren
> Cc: Thierry Reding
> Cc: linux-a...@vger.kernel.org
> Cc: platform-driver-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-o...@vger.kernel.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: Guenter Roeck
> Cc: Rafael J. Wysocki
> Cc: Maxime Ripard
> Cc: Darren Hart
> Cc: lm-sens...@lm-sensors.org
> ---
>
> changes since v1:
> - Add missing pieces for power_allocator driver
>
> drivers/acpi/thermal.c | 12 +-
> drivers/hwmon/lm75.c | 2 +-
> drivers/hwmon/ntc_thermistor.c | 2 +-
> drivers/hwmon/tmp102.c | 2 +-
> drivers/input/touchscreen/sun4i-ts.c | 8 +++
> drivers/platform/x86/acerhdf.c | 9
> drivers/platform/x86/intel_mid_thermal.c | 9
> drivers/power/power_supply_core.c | 2 +-
> drivers/thermal/armada_thermal.c | 2 +-
> drivers/thermal/db8500_thermal.c | 7 +++---
> drivers/thermal/dove_thermal.c | 2 +-
> drivers/thermal/fair_share.c | 2 +-
> drivers/thermal/gov_bang_bang.c| 5 ++--
> drivers/thermal/hisi_thermal.c | 4 ++--
> drivers/thermal/imx_thermal.c | 27
> +++---
> drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +-
> .../thermal/int340x_thermal/int340x_thermal_zone.c | 10
> .../thermal/int340x_thermal/int340x_thermal_zone.h | 8 +++
> .../int340x_thermal/processor_thermal_device.c | 4 ++--
> drivers/thermal/intel_quark_dts_thermal.c | 13 +--
> drivers/thermal/intel_soc_dts_iosf.c | 8 +++
> drivers/thermal/kirkwood_thermal.c | 2 +-
> drivers/thermal/of-thermal.c | 14 +--
> drivers/thermal/power_allocator.c | 16 ++---
> drivers/thermal/qcom-spmi-temp-alarm.c | 2 +-
> drivers/thermal/rcar_thermal.c | 7 +++---
> drivers/thermal/rockchip_thermal.c | 10
> drivers/thermal/samsung/exynos_tmu.c | 23 +-
> drivers/thermal/spear_thermal.c| 2 +-
> drivers/thermal/st/st_thermal.c| 5 ++--
> drivers/thermal/step_wise.c| 4 ++--
> drivers/thermal/tegra_soctherm.c | 4 ++--
> drivers/thermal/thermal_core.c | 26 ++---
> drivers/thermal/thermal_hwmon.c| 10
> drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 10
> drivers/thermal/x86_pkg_temp_thermal.c | 10
> include/linux/thermal.h| 26 +
> include/trace/events/thermal_power_allocator.h | 6 ++---
> 38 files changed, 151 insertions(+), 166 deletions(-)
>
[...]
> diff --git a/drivers/thermal/power_allocator.c
> b/drivers/thermal/power_allocator.c
> index 4672250..045aea59 100644
> --- a/drivers/thermal/power_allocator.c
> +++ b/drivers/thermal/power_allocator.c
> @@ -92,8 +92,8 @@ struct power_allocator_params {
> * Return: The power budget for the next period.
> */
> static u32 pid_controller(struct thermal_zone_device *tz,
> - unsigned long current_temp,
> - unsigned long control_temp,
> + int current_temp,
> + int c
Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.
Hello, On 21 July 2015 at 06:29, Vinod Koul wrote: > On Sun, Jul 19, 2015 at 09:01:34PM +0200, Michal Suchanek wrote: >> Hello, >> >> On 15 July 2015 at 17:59, Brian Norris wrote: >> > Hi Michal, >> > >> > On Wed, Jul 15, 2015 at 01:52:27PM +0200, Marek Vasut wrote: >> >> The problem is, if you add a new DT binding, you'd have to support it >> >> forever, no matter how bad idea that binding turned out to be. >> > >> > Agreed, and a solid NAK to this patch. I could have sworn I gave such a >> > response when this was originally being discussed a month ago. >> > >> > AFAICT, you have one of two general approaches available to you: >> > >> > 1. Fix up the SPI driver so that it knows how to break large SPI >> > transfers up into smaller segments that its constituent hardware (DMA >> > controllers, fast clocks, etc.) can handle. >> > >> > 2. Utilize/create a parameter within the SPI subsystem to communicate >> > that the SPI master has a limited max transfer size (notably: NOT a >> > per-device DT property, but a SPI API property), and modify SPI device >> > drivers (like m25p80) to honor it. Mark Brown seemed open to this, and I >> > thought he suggested it somewhere. >> >> It is not known what exactly is limited here. >> >> It seems that the pl330 fails but it is not possible to transfer that >> much data over the spi bus in one go without the help of the pl330. >> >> With either approach the limit depends on the SPI transfer settings >> which are known the the SPI driver. The pl330 driver is oblivious to >> these because it just transfers data from one port to another port and >> has no idea that the port is wired to SPI in the SoC. >> >> On the other hand, AFAICT the SPI driver only allocates a DMA channel >> which it receives through DT binding and is oblivious to the fact the >> DMA channel lives on a pl330. It could probably determine that the >> channel is indeed driven by a pl330. I don't think it's a great idea >> to add device-specific handling to a generic dmaengine driver or a >> dmaengine-spiecific handling to a SPI driver. >> >> It's technically possible to pass SPI transfer parameters to the >> dmaengine driver prior to transfer and the dmaengine could impose some >> limitation based on those parameters. However, generalising this to >> drivers other than SPI might be problematic. Should this interface >> also handle i2c parameters, VE parameters, audio parameters, ethernet >> parameters, etc? > Or alternatively we could publish the limitations of the channel using > capabilities so SPI knows I have a dmaengine channel and it can transfer max N > length transfers so would be able to break rather than guessing it or coding > in DT. Yes it may come from DT but that should be dmaengine driver rather > than client driver :) > > This can be done by dma_get_slave_caps(chan, &caps) > > And we add max_length as one more parameter to existing set > > Also all this could be handled in generic SPI-dmaengine layer so that > individual drivers don't have to code it in > > Let me know if this idea is okay, I can push the dmaengine bits... > It would be ok if there was a fixed limit. However, the limit depends on SPI slave settings. Presumably for other buses using the dmaengine the limit would depend on the bus or slave settings as well. I do not see a sane way of passing this all the way to the dmaengine driver. Thanks Michal -- 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] drivers/irqchip: replace pr_warning by pr_warn
Update the last pr_warning callsite in drivers/irqchip.
Signed-off-by: Wang Long
---
drivers/irqchip/exynos-combiner.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/exynos-combiner.c
b/drivers/irqchip/exynos-combiner.c
index 5c82e3b..80104f9 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -185,14 +185,14 @@ static void __init combiner_init(void __iomem
*combiner_base,
combiner_data = kcalloc(max_nr, sizeof (*combiner_data), GFP_KERNEL);
if (!combiner_data) {
- pr_warning("%s: could not allocate combiner data\n", __func__);
+ pr_warn("%s: could not allocate combiner data\n", __func__);
return;
}
combiner_irq_domain = irq_domain_add_linear(np, nr_irq,
&combiner_irq_domain_ops, combiner_data);
if (WARN_ON(!combiner_irq_domain)) {
- pr_warning("%s: irq domain init failed\n", __func__);
+ pr_warn("%s: irq domain init failed\n", __func__);
return;
}
--
1.8.3.4
--
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] thermal: consistently use int for temperatures
Hi Punit, On Fri, Jul 17, 2015 at 12:14:36PM +0100, Punit Agrawal wrote: > Hi Sascha, > > Sascha Hauer writes: > > > The thermal code uses int, long and unsigned long for temperatures > > in different places. > > > > Using an unsigned type limits the thermal framework to positive > > temperatures without need. Also several drivers currently will report > > temperatures near UINT_MAX for temperatures below 0°C. This will probably > > immediately shut the machine down due to overtemperature if started below > > 0°C. > > > > 'long' is 64bit on several architectures. This is not needed since INT_MAX > > °mC > > is above the melting point of all known materials. > > > > Consistently use a plain 'int' for temperatures throughout the thermal code > > and > > the drivers. This only changes the places in the drivers where the > > temperature > > is passed around as pointer, when drivers internally use another type this > > is > > not changed. > > > > Signed-off-by: Sascha Hauer > > Thanks for moving over the thermal sub-system in Linux to consistently > use a single type. > > In your patch, you missed migrating over power_allocator governor and > it's associated trace events. It got merged for v4.2. > > Could you incorporate something like below in your next version? It seems I have changed drivers/thermal/power_allocator.c but missed include/trace/events/thermal_power_allocator.h. Please check out the v2 patch I just sent. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 v2] thermal: consistently use int for temperatures
The thermal code uses int, long and unsigned long for temperatures
in different places.
Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.
'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.
Consistently use a plain 'int' for temperatures throughout the thermal code and
the drivers. This only changes the places in the drivers where the temperature
is passed around as pointer, when drivers internally use another type this is
not changed.
Signed-off-by: Sascha Hauer
Acked-by: Geert Uytterhoeven
Reviewed-by: Jean Delvare
Reviewed-by: Lukasz Majewski
Reviewed-by: Darren Hart
Reviewed-by: Heiko Stuebner
Reviewed-by: Peter Feuerer
Cc: Punit Agrawal
Cc: Zhang Rui
Cc: Eduardo Valentin
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Jean Delvare
Cc: Peter Feuerer
Cc: Heiko Stuebner
Cc: Lukasz Majewski
Cc: Stephen Warren
Cc: Thierry Reding
Cc: linux-a...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Guenter Roeck
Cc: Rafael J. Wysocki
Cc: Maxime Ripard
Cc: Darren Hart
Cc: lm-sens...@lm-sensors.org
---
changes since v1:
- Add missing pieces for power_allocator driver
drivers/acpi/thermal.c | 12 +-
drivers/hwmon/lm75.c | 2 +-
drivers/hwmon/ntc_thermistor.c | 2 +-
drivers/hwmon/tmp102.c | 2 +-
drivers/input/touchscreen/sun4i-ts.c | 8 +++
drivers/platform/x86/acerhdf.c | 9
drivers/platform/x86/intel_mid_thermal.c | 9
drivers/power/power_supply_core.c | 2 +-
drivers/thermal/armada_thermal.c | 2 +-
drivers/thermal/db8500_thermal.c | 7 +++---
drivers/thermal/dove_thermal.c | 2 +-
drivers/thermal/fair_share.c | 2 +-
drivers/thermal/gov_bang_bang.c| 5 ++--
drivers/thermal/hisi_thermal.c | 4 ++--
drivers/thermal/imx_thermal.c | 27 +++---
drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +-
.../thermal/int340x_thermal/int340x_thermal_zone.c | 10
.../thermal/int340x_thermal/int340x_thermal_zone.h | 8 +++
.../int340x_thermal/processor_thermal_device.c | 4 ++--
drivers/thermal/intel_quark_dts_thermal.c | 13 +--
drivers/thermal/intel_soc_dts_iosf.c | 8 +++
drivers/thermal/kirkwood_thermal.c | 2 +-
drivers/thermal/of-thermal.c | 14 +--
drivers/thermal/power_allocator.c | 16 ++---
drivers/thermal/qcom-spmi-temp-alarm.c | 2 +-
drivers/thermal/rcar_thermal.c | 7 +++---
drivers/thermal/rockchip_thermal.c | 10
drivers/thermal/samsung/exynos_tmu.c | 23 +-
drivers/thermal/spear_thermal.c| 2 +-
drivers/thermal/st/st_thermal.c| 5 ++--
drivers/thermal/step_wise.c| 4 ++--
drivers/thermal/tegra_soctherm.c | 4 ++--
drivers/thermal/thermal_core.c | 26 ++---
drivers/thermal/thermal_hwmon.c| 10
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 10
drivers/thermal/x86_pkg_temp_thermal.c | 10
include/linux/thermal.h| 26 +
include/trace/events/thermal_power_allocator.h | 6 ++---
38 files changed, 151 insertions(+), 166 deletions(-)
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 6d4e44e..e66ad25 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -529,8 +529,7 @@ static void acpi_thermal_check(void *data)
/* sys I/F for generic thermal sysfs support */
-static int thermal_get_temp(struct thermal_zone_device *thermal,
- unsigned long *temp)
+static int thermal_get_temp(struct thermal_zone_device *thermal, int *temp)
{
struct acpi_thermal *tz = thermal->devdata;
int result;
@@ -637,7 +636,7 @@ static int thermal_get_trip_type(struct thermal_zone_device
*thermal,
}
static int thermal_get_trip_temp(struct thermal_zone_device *thermal,
-int trip, unsigned long *temp)
+int trip, int *temp)
{
struct acpi_thermal *tz = thermal->devdata;
int i;
@@ -690,7 +689,8 @@ static in
