[-- Attachment #1: Type: text/plain, Size: 2584 bytes --] On Mon, Mar 18, 2024 at 05:20:50PM +0100, Krzysztof Kozlowski wrote: > On 17/03/2024 16:49, Conor Dooley wrote: > > On Sun, Mar 17, 2024 at 04:26:55PM +0100, Krzysztof Kozlowski wrote: > >> On 17/03/2024 16:23, Conor Dooley wrote: > >>> On Tue, Mar 12, 2024 at 07:50:35PM +0100, Krzysztof Kozlowski wrote: > >>>> Convert Samsung S3C6400/S3C6410 SoC clock controller bindings to DT > >>>> schema. > >>> > >>>> +description: | > >>>> + There are several clocks that are generated outside the SoC. It is expected > >>>> + that they are defined using standard clock bindings with following > >>>> + clock-output-names: > >>>> + - "fin_pll" - PLL input clock (xtal/extclk) - required, > >>>> + - "xusbxti" - USB xtal - required, > >>>> + - "iiscdclk0" - I2S0 codec clock - optional, > >>>> + - "iiscdclk1" - I2S1 codec clock - optional, > >>>> + - "iiscdclk2" - I2S2 codec clock - optional, > >>>> + - "pcmcdclk0" - PCM0 codec clock - optional, > >>>> + - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410. > >>> > >>> I know you've only transfered this from the text binding, but what is > >>> the relevance of this to the binding for this clock controller? This > >>> seems to be describing some ?fixed? clocks that must be provided in > >>> addition to this controller. I guess there's probably no other suitable > >>> place to mention these? > >> > >> To make it correct, these should be made clock inputs to the clock > >> controller, even if the driver does not take them, however that's > >> obsolete platform which might be removed from kernel this or next year, > >> so I don't want to spend time on it. > > > > I think the comment should probably mention that these are the expected > > inputs, part of me thought that that was what you were getting at but I > > wasn't sure if instead they were inputs to some other IP on the SoC. > > I can change it, but just to emphasize: in half a year or next year we > will probably remove entire platform, thus also this binding. I know, I saw that. I don't really care what you do given the platform is being deleted and it is unlikely that anyone is actually going to be assembling a from-scratch dtsi for this SoC. On the other hand, if you're doing a conversion, even in this scenario, I think it should be clear. I didn't ack the patch cos I figured you were taking the patch via the samsung tree (and on to Stephen) yourself, but here: Acked-by: Conor Dooley <conor.dooley@microchip.com> I'd rather argue about the definition of erratum instead of this :) [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --]
On 17/03/2024 16:49, Conor Dooley wrote:
> On Sun, Mar 17, 2024 at 04:26:55PM +0100, Krzysztof Kozlowski wrote:
>> On 17/03/2024 16:23, Conor Dooley wrote:
>>> On Tue, Mar 12, 2024 at 07:50:35PM +0100, Krzysztof Kozlowski wrote:
>>>> Convert Samsung S3C6400/S3C6410 SoC clock controller bindings to DT
>>>> schema.
>>>
>>>> +description: |
>>>> + There are several clocks that are generated outside the SoC. It is expected
>>>> + that they are defined using standard clock bindings with following
>>>> + clock-output-names:
>>>> + - "fin_pll" - PLL input clock (xtal/extclk) - required,
>>>> + - "xusbxti" - USB xtal - required,
>>>> + - "iiscdclk0" - I2S0 codec clock - optional,
>>>> + - "iiscdclk1" - I2S1 codec clock - optional,
>>>> + - "iiscdclk2" - I2S2 codec clock - optional,
>>>> + - "pcmcdclk0" - PCM0 codec clock - optional,
>>>> + - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410.
>>>
>>> I know you've only transfered this from the text binding, but what is
>>> the relevance of this to the binding for this clock controller? This
>>> seems to be describing some ?fixed? clocks that must be provided in
>>> addition to this controller. I guess there's probably no other suitable
>>> place to mention these?
>>
>> To make it correct, these should be made clock inputs to the clock
>> controller, even if the driver does not take them, however that's
>> obsolete platform which might be removed from kernel this or next year,
>> so I don't want to spend time on it.
>
> I think the comment should probably mention that these are the expected
> inputs, part of me thought that that was what you were getting at but I
> wasn't sure if instead they were inputs to some other IP on the SoC.
I can change it, but just to emphasize: in half a year or next year we
will probably remove entire platform, thus also this binding.
Best regards,
Krzysztof
Switch to using drm_driver_legacy_fb_format() instead of drm_mode_legacy_fb_format() to use the same logic as for the DRM_IOCTL_MODE_ADDFB ioctl when selecting a framebuffer format. Signed-off-by: Frej Drejhammar <frej.drejhammar@gmail.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: Alim Akhtar <alim.akhtar@samsung.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org --- This is an evolved version of the changes proposed in "drm: Don't return unsupported formats in drm_mode_legacy_fb_format" [1] following the suggestions of Thomas Zimmermann. [1] https://lore.kernel.org/all/20240310152803.3315-1-frej.drejhammar@gmail.com/ --- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index a379c8ca435a..d47bb5e89ff2 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c @@ -104,8 +104,10 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper *helper, mode_cmd.width = sizes->surface_width; mode_cmd.height = sizes->surface_height; mode_cmd.pitches[0] = sizes->surface_width * (sizes->surface_bpp >> 3); - mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, - sizes->surface_depth); + mode_cmd.pixel_format = + drm_driver_legacy_fb_format(dev, + sizes->surface_bpp, + sizes->surface_depth); size = mode_cmd.pitches[0] * mode_cmd.height; -- 2.44.0
When userland uses DRM_IOCTL_MODE_ADDFB to add a framebuffer, the DRM subsystem tries to find a pixel format from the supplied depth and bpp-values. It does this by calling drm_driver_legacy_fb_format(). Unfortunately drm_driver_legacy_fb_format() can return formats not supported by the underlying hardware. This series of patches remedies this problem in patch 1. In order to use the same logic for determining the pixel format, when a fbdev adds a framebuffer as userland does, patches 2 to 11 migrates fbdev users of drm_mode_legacy_fb_format() to drm_driver_legacy_fb_format(). This series has been tested with the nouveau and modesetting drivers on a NVIDIA NV96, the modesetting driver on Beagleboard Black, and with the Intel and modesetting drivers on an Intel HD Graphics 4000 chipset. This is an evolved version of the changes proposed in "drm: Don't return unsupported formats in drm_mode_legacy_fb_format" [1] following the suggestions of Thomas Zimmermann. Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Alim Akhtar <alim.akhtar@samsung.com> Cc: amd-gfx@lists.freedesktop.org Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@gmail.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: intel-xe@lists.freedesktop.org Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-tegra@vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: "Maíra Canal" <mcanal@igalia.com> Cc: Marijn Suijten <marijn.suijten@somainline.org> Cc: Maxime Ripard <mripard@kernel.org> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Sean Paul <sean@poorly.run> Cc: stable@vger.kernel.org Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> [1] https://lore.kernel.org/all/20240310152803.3315-1-frej.drejhammar@gmail.com/ Frej Drejhammar (11): drm: Only return supported formats from drm_driver_legacy_fb_format drm/fbdev_generic: Use drm_driver_legacy_fb_format() for fbdev drm/armada: Use drm_driver_legacy_fb_format() for fbdev drm/exynos: Use drm_driver_legacy_fb_format() for fbdev drm/gma500: Use drm_driver_legacy_fb_format() for fbdev drm/i915: Use drm_driver_legacy_fb_format() for fbdev drm/msm: Use drm_driver_legacy_fb_format() for fbdev drm/omapdrm: Use drm_driver_legacy_fb_format() for fbdev drm/radeon: Use drm_driver_legacy_fb_format() for fbdev drm/tegra: Use drm_driver_legacy_fb_format() for fbdev drm/xe: Use drm_driver_legacy_fb_format() for fbdev drivers/gpu/drm/armada/armada_fbdev.c | 5 +- drivers/gpu/drm/drm_fb_helper.c | 2 +- drivers/gpu/drm/drm_fbdev_dma.c | 4 +- drivers/gpu/drm/drm_fbdev_generic.c | 4 +- drivers/gpu/drm/drm_fourcc.c | 83 +++++++++++++++++++ drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 6 +- drivers/gpu/drm/gma500/fbdev.c | 2 +- drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 6 +- drivers/gpu/drm/msm/msm_fbdev.c | 4 +- drivers/gpu/drm/omapdrm/omap_fbdev.c | 6 +- drivers/gpu/drm/radeon/radeon_fbdev.c | 6 +- drivers/gpu/drm/tegra/fbdev.c | 5 +- drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 5 +- 13 files changed, 119 insertions(+), 19 deletions(-) base-commit: 119b225f01e4d3ce974cd3b4d982c76a380c796d -- 2.44.0
[-- Attachment #1: Type: text/plain, Size: 1704 bytes --] On Sun, Mar 17, 2024 at 04:26:55PM +0100, Krzysztof Kozlowski wrote: > On 17/03/2024 16:23, Conor Dooley wrote: > > On Tue, Mar 12, 2024 at 07:50:35PM +0100, Krzysztof Kozlowski wrote: > >> Convert Samsung S3C6400/S3C6410 SoC clock controller bindings to DT > >> schema. > > > >> +description: | > >> + There are several clocks that are generated outside the SoC. It is expected > >> + that they are defined using standard clock bindings with following > >> + clock-output-names: > >> + - "fin_pll" - PLL input clock (xtal/extclk) - required, > >> + - "xusbxti" - USB xtal - required, > >> + - "iiscdclk0" - I2S0 codec clock - optional, > >> + - "iiscdclk1" - I2S1 codec clock - optional, > >> + - "iiscdclk2" - I2S2 codec clock - optional, > >> + - "pcmcdclk0" - PCM0 codec clock - optional, > >> + - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410. > > > > I know you've only transfered this from the text binding, but what is > > the relevance of this to the binding for this clock controller? This > > seems to be describing some ?fixed? clocks that must be provided in > > addition to this controller. I guess there's probably no other suitable > > place to mention these? > > To make it correct, these should be made clock inputs to the clock > controller, even if the driver does not take them, however that's > obsolete platform which might be removed from kernel this or next year, > so I don't want to spend time on it. I think the comment should probably mention that these are the expected inputs, part of me thought that that was what you were getting at but I wasn't sure if instead they were inputs to some other IP on the SoC. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --]
On 17/03/2024 16:23, Conor Dooley wrote:
> On Tue, Mar 12, 2024 at 07:50:35PM +0100, Krzysztof Kozlowski wrote:
>> Convert Samsung S3C6400/S3C6410 SoC clock controller bindings to DT
>> schema.
>
>> +description: |
>> + There are several clocks that are generated outside the SoC. It is expected
>> + that they are defined using standard clock bindings with following
>> + clock-output-names:
>> + - "fin_pll" - PLL input clock (xtal/extclk) - required,
>> + - "xusbxti" - USB xtal - required,
>> + - "iiscdclk0" - I2S0 codec clock - optional,
>> + - "iiscdclk1" - I2S1 codec clock - optional,
>> + - "iiscdclk2" - I2S2 codec clock - optional,
>> + - "pcmcdclk0" - PCM0 codec clock - optional,
>> + - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410.
>
> I know you've only transfered this from the text binding, but what is
> the relevance of this to the binding for this clock controller? This
> seems to be describing some ?fixed? clocks that must be provided in
> addition to this controller. I guess there's probably no other suitable
> place to mention these?
To make it correct, these should be made clock inputs to the clock
controller, even if the driver does not take them, however that's
obsolete platform which might be removed from kernel this or next year,
so I don't want to spend time on it.
Best regards,
Krzysztof
[-- Attachment #1: Type: text/plain, Size: 1022 bytes --] On Tue, Mar 12, 2024 at 07:50:35PM +0100, Krzysztof Kozlowski wrote: > Convert Samsung S3C6400/S3C6410 SoC clock controller bindings to DT > schema. > +description: | > + There are several clocks that are generated outside the SoC. It is expected > + that they are defined using standard clock bindings with following > + clock-output-names: > + - "fin_pll" - PLL input clock (xtal/extclk) - required, > + - "xusbxti" - USB xtal - required, > + - "iiscdclk0" - I2S0 codec clock - optional, > + - "iiscdclk1" - I2S1 codec clock - optional, > + - "iiscdclk2" - I2S2 codec clock - optional, > + - "pcmcdclk0" - PCM0 codec clock - optional, > + - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410. I know you've only transfered this from the text binding, but what is the relevance of this to the binding for this clock controller? This seems to be describing some ?fixed? clocks that must be provided in addition to this controller. I guess there's probably no other suitable place to mention these? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --]
On 22.02.2024 16:55, Krzysztof Kozlowski wrote: > On 21/02/2024 09:26, Krzysztof Kozlowski wrote: >> On 19/02/2024 20:49, Artur Weber wrote: >>> On 19.02.2024 08:44, Krzysztof Kozlowski wrote: >>>> On 17/02/2024 20:02, Artur Weber wrote: >>>>> The stock bootloader on the Samsung Galaxy Tab 3 8.0 provides an >>>>> incorrect available memory range over ATAG_MEM. Limit the usable >>>>> memory in the DTS to prevent it from doing so, without having to >>>>> disable ATAG support. >>>>> >>>>> Signed-off-by: Artur Weber <aweber.kernel@gmail.com> >>>>> --- >>>>> arch/arm/boot/dts/samsung/exynos4212-tab3.dtsi | 6 ++++++ >>>>> 1 file changed, 6 insertions(+) >>>>> >>>>> diff --git a/arch/arm/boot/dts/samsung/exynos4212-tab3.dtsi b/arch/arm/boot/dts/samsung/exynos4212-tab3.dtsi >>>>> index e5254e32aa8f..9bc05961577d 100644 >>>>> --- a/arch/arm/boot/dts/samsung/exynos4212-tab3.dtsi >>>>> +++ b/arch/arm/boot/dts/samsung/exynos4212-tab3.dtsi >>>>> @@ -45,6 +45,12 @@ chosen { >>>>> /* Default S-BOOT bootloader loads initramfs here */ >>>>> linux,initrd-start = <0x42000000>; >>>>> linux,initrd-end = <0x42800000>; >>>>> + >>>>> + /* >>>>> + * Stock bootloader provides incorrect memory size in ATAG_MEM; >>>>> + * override it here >>>>> + */ >>>>> + linux,usable-memory-range = <0x40000000 0x3fc00000>; >>>> >>>> Applied and dropped: >>>> chosen: linux,usable-memory-range:0: [4611686019496935424] is too short >>> >>> This seems to be a binding issue; the DT schema expects a 64-bit memory >>> address and size, and doesn't allow a 32-bit range. I've tested the DTS >>> on my device and this property seems to be handled fine, so I think this >>> should allow 32-bit values as well. >> >> Regardless where is the issue: please test before sending. >> >>> >>> I've opened a PR[1] against devicetree-org/dt-schema (where the schema >>> for the chosen node is stored) to try and fix this. If my approach is >>> incorrect, feel free to comment there as well. >> >> >> According to Rob's comments, the DTS is the issue. > > With updated dtschema I still see the same warning. Is something else > missing? My bad, turns out I didn't test my dt-schemas patch correctly... looks like this has been *properly* fixed now in latest dt-schema[1][2], and I no longer get warnings about the linux,usable-memory-range property. (There are some new warnings though, for some nodes in exynos4.dtsi that have 2 reg values, but that's out of scope for this patch.) Sorry for the general confusion, I'll make sure to double-check my patches next time... Best regards Artur [1] https://github.com/devicetree-org/dt-schema/commit/08eff8e6167e9e0bc1694af6c298b4584105a057 [2] https://github.com/devicetree-org/dt-schema/commit/c95c9ad63c51f8d9cfb258e6f17a8001efab6d64
Hi David,
On Fri, Mar 15, 2024 at 02:33:53PM -0700, David Rientjes wrote:
> Joerg, is this series anticipated to be queued up in the core branch of
> git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git so it gets into
> linux-next?
>
> This observability seems particularly useful so that we can monitor and
> alert on any unexpected increases (unbounded memory growth from this
> subsystem has in the past caused us issues before the memory is otherwise
> not observable by host software).
>
> Or are we still waiting on code reviews from some folks that we should
> ping?
A few more reviews would certainly help, but I will also do a review on
my own. If things are looking good I can merge it into the iommu tree
when 6.9-rc3 is released (which is the usual time I start merging new
stuff).
Regards,
Joerg
On Thu, 22 Feb 2024, Pasha Tatashin wrote:
> Pasha Tatashin (11):
> iommu/vt-d: add wrapper functions for page allocations
> iommu/dma: use iommu_put_pages_list() to releae freelist
> iommu/amd: use page allocation function provided by iommu-pages.h
> iommu/io-pgtable-arm: use page allocation function provided by
> iommu-pages.h
> iommu/io-pgtable-dart: use page allocation function provided by
> iommu-pages.h
> iommu/exynos: use page allocation function provided by iommu-pages.h
> iommu/rockchip: use page allocation function provided by iommu-pages.h
> iommu/sun50i: use page allocation function provided by iommu-pages.h
> iommu/tegra-smmu: use page allocation function provided by
> iommu-pages.h
> iommu: observability of the IOMMU allocations
> iommu: account IOMMU allocated memory
>
> Documentation/admin-guide/cgroup-v2.rst | 2 +-
> Documentation/filesystems/proc.rst | 4 +-
> drivers/iommu/amd/amd_iommu.h | 8 -
> drivers/iommu/amd/init.c | 91 ++++++------
> drivers/iommu/amd/io_pgtable.c | 13 +-
> drivers/iommu/amd/io_pgtable_v2.c | 20 +--
> drivers/iommu/amd/iommu.c | 13 +-
> drivers/iommu/dma-iommu.c | 7 +-
> drivers/iommu/exynos-iommu.c | 14 +-
> drivers/iommu/intel/dmar.c | 16 +-
> drivers/iommu/intel/iommu.c | 47 ++----
> drivers/iommu/intel/iommu.h | 2 -
> drivers/iommu/intel/irq_remapping.c | 16 +-
> drivers/iommu/intel/pasid.c | 18 +--
> drivers/iommu/intel/svm.c | 11 +-
> drivers/iommu/io-pgtable-arm.c | 15 +-
> drivers/iommu/io-pgtable-dart.c | 37 ++---
> drivers/iommu/iommu-pages.h | 186 ++++++++++++++++++++++++
> drivers/iommu/rockchip-iommu.c | 14 +-
> drivers/iommu/sun50i-iommu.c | 7 +-
> drivers/iommu/tegra-smmu.c | 18 ++-
> include/linux/mmzone.h | 5 +-
> mm/vmstat.c | 3 +
> 23 files changed, 361 insertions(+), 206 deletions(-)
> create mode 100644 drivers/iommu/iommu-pages.h
>
Joerg, is this series anticipated to be queued up in the core branch of
git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git so it gets into
linux-next?
This observability seems particularly useful so that we can monitor and
alert on any unexpected increases (unbounded memory growth from this
subsystem has in the past caused us issues before the memory is otherwise
not observable by host software).
Or are we still waiting on code reviews from some folks that we should
ping?
Thanks!
On Thu, 22 Feb 2024, Pasha Tatashin wrote:
> Free the IOMMU page tables via iommu_put_pages_list(). The page tables
> were allocated via iommu_alloc_* functions in architecture specific
> places, but are released in dma-iommu if the freelist is gathered during
> map/unmap operations into iommu_iotlb_gather data structure.
>
> Currently, only iommu/intel that does that.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Acked-by: David Rientjes <rientjes@google.com>
Quoting Shradha Todi (2024-03-15 04:34:44)
> >
> > Quoting Shradha Todi (2024-03-06 04:13:03)
> > > >
> > > > When clk_bulk_get_all() returns zero then we return success here.
> > > >
> > >
> > > Yes, we are returning success in case there are no clocks as well. In
> > > case there are no clocks defined in the DT-node, then it is assumed
> > > that the driver does not need any clock manipulation for driver
> > > operation. So the intention here is to continue without throwing
> > > error.
> >
> > Maybe we shouldn't even return the clks to the caller. Do you have any use for
> > the clk pointers?
>
> The intention to return the clk pointers was in the case where caller wants to
> manipulate a particular clock in certain conditions. They can obtain the clock pointer
> and use clk_set_parent, clk_set_rate on those particular clocks.
> But I understand that in that case users can use existing clk_bulk_get_all() API.
> So, should I go ahead and send v7?
>
No, I think this is fine.
Hi Lukasz, kernel test robot noticed the following build warnings: [auto build test WARNING on rafael-pm/linux-next] [also build test WARNING on linus/master next-20240315] [cannot apply to krzk/for-next clk/clk-next soc/for-next rafael-pm/acpi-bus rafael-pm/devprop v6.8] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Lukasz-Luba/OPP-OF-Export-dev_opp_pm_calc_power-for-usage-from-EM/20240314-220719 base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next patch link: https://lore.kernel.org/r/20240314140421.3563571-4-lukasz.luba%40arm.com patch subject: [PATCH 3/4] PM: EM: Add em_dev_update_chip_binning() config: i386-randconfig-141-20240315 (https://download.01.org/0day-ci/archive/20240316/202403160033.Kh6R75dh-lkp@intel.com/config) compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240316/202403160033.Kh6R75dh-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202403160033.Kh6R75dh-lkp@intel.com/ All warnings (new ones prefixed by >>): >> kernel/power/energy_model.c:824:52: warning: variable 'ret' is uninitialized when used here [-Wuninitialized] 824 | dev_warn(dev, "Couldn't find Energy Model %d\n", ret); | ^~~ include/linux/dev_printk.h:146:70: note: expanded from macro 'dev_warn' 146 | dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev, dev_fmt(fmt), ##__VA_ARGS__) | ^~~~~~~~~~~ include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap' 110 | _p_func(dev, fmt, ##__VA_ARGS__); \ | ^~~~~~~~~~~ kernel/power/energy_model.c:817:12: note: initialize the variable 'ret' to silence this warning 817 | int i, ret; | ^ | = 0 1 warning generated. vim +/ret +824 kernel/power/energy_model.c 800 801 /** 802 * em_dev_update_chip_binning() - Update Energy Model with new values after 803 * the new voltage information is present in the OPPs. 804 * @dev : Device for which the Energy Model has to be updated. 805 * 806 * This function allows to update easily the EM with new values available in 807 * the OPP framework and DT. It can be used after the chip has been properly 808 * verified by device drivers and the voltages adjusted for the 'chip binning'. 809 * It uses the "dynamic-power-coefficient" DT property to calculate the power 810 * values for EM. For power calculation it uses the new adjusted voltage 811 * values known for OPPs, which might be changed after boot. 812 */ 813 int em_dev_update_chip_binning(struct device *dev) 814 { 815 struct em_perf_table __rcu *em_table; 816 struct em_perf_domain *pd; 817 int i, ret; 818 819 if (IS_ERR_OR_NULL(dev)) 820 return -EINVAL; 821 822 pd = em_pd_get(dev); 823 if (!pd) { > 824 dev_warn(dev, "Couldn't find Energy Model %d\n", ret); -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
On Wed, 13 Mar 2024 19:43:17 +0100, Krzysztof Kozlowski wrote:
> Document binding for Samsung S5Pv210 SoC OneNAND controller used already
> in S5Pv210 DTS.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
> .../bindings/mtd/samsung,s5pv210-onenand.yaml | 65 +++++++++++++++++++
> 1 file changed, 65 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/samsung,s5pv210-onenand.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
On Tue, 12 Mar 2024 20:03:48 +0100, Krzysztof Kozlowski wrote:
> Document bindings for the S5Pv210 SoC DMC memory controller, already
> used in DTS and Linux CPU frequency scaling driver. The binding looks
> quite empty and is most likely incomplete, but the platform is so old
> that no one expects any effort on this, except documenting what is in
> DTS.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
> .../samsung,s5pv210-dmc.yaml | 33 +++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/samsung,s5pv210-dmc.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
Hi Lukasz, kernel test robot noticed the following build warnings: [auto build test WARNING on rafael-pm/linux-next] [also build test WARNING on linus/master next-20240315] [cannot apply to krzk/for-next clk/clk-next soc/for-next rafael-pm/acpi-bus rafael-pm/devprop v6.8] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Lukasz-Luba/OPP-OF-Export-dev_opp_pm_calc_power-for-usage-from-EM/20240314-220719 base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next patch link: https://lore.kernel.org/r/20240314140421.3563571-4-lukasz.luba%40arm.com patch subject: [PATCH 3/4] PM: EM: Add em_dev_update_chip_binning() config: x86_64-randconfig-123-20240315 (https://download.01.org/0day-ci/archive/20240315/202403152322.1OIlZSAj-lkp@intel.com/config) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240315/202403152322.1OIlZSAj-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202403152322.1OIlZSAj-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) kernel/power/energy_model.c:168:15: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct em_perf_table [noderef] __rcu *table @@ got struct em_perf_table * @@ kernel/power/energy_model.c:168:15: sparse: expected struct em_perf_table [noderef] __rcu *table kernel/power/energy_model.c:168:15: sparse: got struct em_perf_table * kernel/power/energy_model.c:169:15: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const *objp @@ got struct em_perf_table [noderef] __rcu *table @@ kernel/power/energy_model.c:169:15: sparse: expected void const *objp kernel/power/energy_model.c:169:15: sparse: got struct em_perf_table [noderef] __rcu *table kernel/power/energy_model.c:177:15: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct em_perf_table [noderef] __rcu *table @@ got struct em_perf_table * @@ kernel/power/energy_model.c:177:15: sparse: expected struct em_perf_table [noderef] __rcu *table kernel/power/energy_model.c:177:15: sparse: got struct em_perf_table * kernel/power/energy_model.c:179:19: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct callback_head *head @@ got struct callback_head [noderef] __rcu * @@ kernel/power/energy_model.c:179:19: sparse: expected struct callback_head *head kernel/power/energy_model.c:179:19: sparse: got struct callback_head [noderef] __rcu * kernel/power/energy_model.c:190:19: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct kref *kref @@ got struct kref [noderef] __rcu * @@ kernel/power/energy_model.c:190:19: sparse: expected struct kref *kref kernel/power/energy_model.c:190:19: sparse: got struct kref [noderef] __rcu * kernel/power/energy_model.c:208:15: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct em_perf_table [noderef] __rcu *table @@ got void * @@ kernel/power/energy_model.c:208:15: sparse: expected struct em_perf_table [noderef] __rcu *table kernel/power/energy_model.c:208:15: sparse: got void * kernel/power/energy_model.c:212:20: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct kref *kref @@ got struct kref [noderef] __rcu * @@ kernel/power/energy_model.c:212:20: sparse: expected struct kref *kref kernel/power/energy_model.c:212:20: sparse: got struct kref [noderef] __rcu * kernel/power/energy_model.c:328:19: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct kref *kref @@ got struct kref [noderef] __rcu * @@ kernel/power/energy_model.c:328:19: sparse: expected struct kref *kref kernel/power/energy_model.c:328:19: sparse: got struct kref [noderef] __rcu * kernel/power/energy_model.c:333:45: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected struct em_perf_state *table @@ got struct em_perf_state [noderef] __rcu * @@ kernel/power/energy_model.c:333:45: sparse: expected struct em_perf_state *table kernel/power/energy_model.c:333:45: sparse: got struct em_perf_state [noderef] __rcu * kernel/power/energy_model.c:433:45: sparse: sparse: incorrect type in argument 3 (different address spaces) @@ expected struct em_perf_state *table @@ got struct em_perf_state [noderef] __rcu * @@ kernel/power/energy_model.c:433:45: sparse: expected struct em_perf_state *table kernel/power/energy_model.c:433:45: sparse: got struct em_perf_state [noderef] __rcu * kernel/power/energy_model.c:450:15: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const *objp @@ got struct em_perf_table [noderef] __rcu *[assigned] em_table @@ kernel/power/energy_model.c:450:15: sparse: expected void const *objp kernel/power/energy_model.c:450:15: sparse: got struct em_perf_table [noderef] __rcu *[assigned] em_table kernel/power/energy_model.c:621:55: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected struct em_perf_state *table @@ got struct em_perf_state [noderef] __rcu * @@ kernel/power/energy_model.c:621:55: sparse: expected struct em_perf_state *table kernel/power/energy_model.c:621:55: sparse: got struct em_perf_state [noderef] __rcu * kernel/power/energy_model.c:676:16: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct em_perf_state *new_ps @@ got struct em_perf_state [noderef] __rcu * @@ kernel/power/energy_model.c:676:16: sparse: expected struct em_perf_state *new_ps kernel/power/energy_model.c:676:16: sparse: got struct em_perf_state [noderef] __rcu * kernel/power/energy_model.c:694:37: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected struct em_perf_state *table @@ got struct em_perf_state [noderef] __rcu * @@ kernel/power/energy_model.c:694:37: sparse: expected struct em_perf_state *table kernel/power/energy_model.c:694:37: sparse: got struct em_perf_state [noderef] __rcu * kernel/power/energy_model.c:729:38: sparse: sparse: incorrect type in argument 3 (different address spaces) @@ expected struct em_perf_state *table @@ got struct em_perf_state [noderef] __rcu * @@ kernel/power/energy_model.c:729:38: sparse: expected struct em_perf_state *table kernel/power/energy_model.c:729:38: sparse: got struct em_perf_state [noderef] __rcu * >> kernel/power/energy_model.c:836:53: sparse: sparse: dereference of noderef expression kernel/power/energy_model.c:845:32: sparse: sparse: dereference of noderef expression vim +836 kernel/power/energy_model.c 800 801 /** 802 * em_dev_update_chip_binning() - Update Energy Model with new values after 803 * the new voltage information is present in the OPPs. 804 * @dev : Device for which the Energy Model has to be updated. 805 * 806 * This function allows to update easily the EM with new values available in 807 * the OPP framework and DT. It can be used after the chip has been properly 808 * verified by device drivers and the voltages adjusted for the 'chip binning'. 809 * It uses the "dynamic-power-coefficient" DT property to calculate the power 810 * values for EM. For power calculation it uses the new adjusted voltage 811 * values known for OPPs, which might be changed after boot. 812 */ 813 int em_dev_update_chip_binning(struct device *dev) 814 { 815 struct em_perf_table __rcu *em_table; 816 struct em_perf_domain *pd; 817 int i, ret; 818 819 if (IS_ERR_OR_NULL(dev)) 820 return -EINVAL; 821 822 pd = em_pd_get(dev); 823 if (!pd) { 824 dev_warn(dev, "Couldn't find Energy Model %d\n", ret); 825 return -EINVAL; 826 } 827 828 em_table = em_table_dup(pd); 829 if (!em_table) { 830 dev_warn(dev, "EM: allocation failed\n"); 831 return -ENOMEM; 832 } 833 834 /* Update power values which might change due to new voltage in OPPs */ 835 for (i = 0; i < pd->nr_perf_states; i++) { > 836 unsigned long freq = em_table->state[i].frequency; -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: 09 March 2024 06:21
> To: 'Dan Carpenter' <dan.carpenter@linaro.org>; Shradha Todi
> <shradha.t@samsung.com>
> Cc: linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-samsung-
> soc@vger.kernel.org; mturquette@baylibre.com; jingoohan1@gmail.com;
> lpieralisi@kernel.org; kw@linux.com; robh@kernel.org; bhelgaas@google.com;
> krzysztof.kozlowski@linaro.org; alim.akhtar@samsung.com;
> linux@armlinux.org.uk; m.szyprowski@samsung.com;
> manivannan.sadhasivam@linaro.org; pankaj.dubey@samsung.com;
> gost.dev@samsung.com
> Subject: RE: [PATCH v6 1/2] clk: Provide managed helper to get and enable bulk
> clocks
>
> Quoting Shradha Todi (2024-03-06 04:13:03)
> > >
> > > When clk_bulk_get_all() returns zero then we return success here.
> > >
> >
> > Yes, we are returning success in case there are no clocks as well. In
> > case there are no clocks defined in the DT-node, then it is assumed
> > that the driver does not need any clock manipulation for driver
> > operation. So the intention here is to continue without throwing
> > error.
>
> Maybe we shouldn't even return the clks to the caller. Do you have any use for
> the clk pointers?
The intention to return the clk pointers was in the case where caller wants to
manipulate a particular clock in certain conditions. They can obtain the clock pointer
and use clk_set_parent, clk_set_rate on those particular clocks.
But I understand that in that case users can use existing clk_bulk_get_all() API.
So, should I go ahead and send v7?
On 14/03/2024 14:04, Lukasz Luba wrote: > Add a function which allows to modify easily the EM after the new voltage > information is available. The device drivers for the chip can adjust > the voltage values after setup. The voltage for the same frequency in OPP > can be different due to chip binning. The voltage impacts the power usage > and the EM power values can be updated to reflect that. > > Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> > --- > include/linux/energy_model.h | 5 ++++ > kernel/power/energy_model.c | 51 ++++++++++++++++++++++++++++++++++++ > 2 files changed, 56 insertions(+) > > diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h > index 770755df852f1..d30d67c2f07cf 100644 > --- a/include/linux/energy_model.h > +++ b/include/linux/energy_model.h > @@ -172,6 +172,7 @@ struct em_perf_table __rcu *em_table_alloc(struct em_perf_domain *pd); > void em_table_free(struct em_perf_table __rcu *table); > int em_dev_compute_costs(struct device *dev, struct em_perf_state *table, > int nr_states); > +int em_dev_update_chip_binning(struct device *dev); > > /** > * em_pd_get_efficient_state() - Get an efficient performance state from the EM > @@ -387,6 +388,10 @@ int em_dev_compute_costs(struct device *dev, struct em_perf_state *table, > { > return -EINVAL; > } > +static inline int em_dev_update_chip_binning(struct device *dev) > +{ > + return -EINVAL; > +} > #endif > > #endif > diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c > index 6960dd7393b2d..1494a909844a4 100644 > --- a/kernel/power/energy_model.c > +++ b/kernel/power/energy_model.c > @@ -808,3 +808,54 @@ static void em_update_workfn(struct work_struct *work) > { > em_check_capacity_update(); > } > + > +/** > + * em_dev_update_chip_binning() - Update Energy Model with new values after > + * the new voltage information is present in the OPPs. > + * @dev : Device for which the Energy Model has to be updated. > + * > + * This function allows to update easily the EM with new values available in > + * the OPP framework and DT. It can be used after the chip has been properly > + * verified by device drivers and the voltages adjusted for the 'chip binning'. > + * It uses the "dynamic-power-coefficient" DT property to calculate the power > + * values for EM. For power calculation it uses the new adjusted voltage > + * values known for OPPs, which might be changed after boot. > + */ > +int em_dev_update_chip_binning(struct device *dev) > +{ > + struct em_perf_table __rcu *em_table; > + struct em_perf_domain *pd; > + int i, ret; > + > + if (IS_ERR_OR_NULL(dev)) > + return -EINVAL; > + > + pd = em_pd_get(dev); > + if (!pd) { > + dev_warn(dev, "Couldn't find Energy Model %d\n", ret); ret is uninitialized at this point, I guess just + dev_warn(dev, "Couldn't find Energy Model\n"); already contains everything relevant. > [...]
When the voltage for OPPs is adjusted there is a need to also update Energy Model framework. The EM data contains power values which depend on voltage values. The EM structure is used for thermal (IPA governor) and in scheduler task placement (EAS) so it should reflect the real HW model as best as possible to operate properly. Based on data on Exynos5422 ASV tables the maximum power difference might be ~29%. An Odroid-XU4 (with a random sample SoC in this chip lottery) showed power difference for some OPPs ~20%. Therefore, it's worth to update the EM. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> --- drivers/soc/samsung/exynos-asv.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/soc/samsung/exynos-asv.c b/drivers/soc/samsung/exynos-asv.c index d60af8acc3916..bd6bb2cab2cd8 100644 --- a/drivers/soc/samsung/exynos-asv.c +++ b/drivers/soc/samsung/exynos-asv.c @@ -11,6 +11,7 @@ #include <linux/cpu.h> #include <linux/device.h> +#include <linux/energy_model.h> #include <linux/errno.h> #include <linux/of.h> #include <linux/pm_opp.h> @@ -97,9 +98,17 @@ static int exynos_asv_update_opps(struct exynos_asv *asv) last_opp_table = opp_table; ret = exynos_asv_update_cpu_opps(asv, cpu); - if (ret < 0) + if (!ret) { + /* + * When the voltage for OPPs successfully + * changed, update the EM power values to + * reflect the reality and not use stale data + */ + em_dev_update_chip_binning(cpu); + } else { dev_err(asv->dev, "Couldn't udate OPPs for cpu%d\n", cpuid); + } } dev_pm_opp_put_opp_table(opp_table); -- 2.25.1
Add a function which allows to modify easily the EM after the new voltage information is available. The device drivers for the chip can adjust the voltage values after setup. The voltage for the same frequency in OPP can be different due to chip binning. The voltage impacts the power usage and the EM power values can be updated to reflect that. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> --- include/linux/energy_model.h | 5 ++++ kernel/power/energy_model.c | 51 ++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+) diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h index 770755df852f1..d30d67c2f07cf 100644 --- a/include/linux/energy_model.h +++ b/include/linux/energy_model.h @@ -172,6 +172,7 @@ struct em_perf_table __rcu *em_table_alloc(struct em_perf_domain *pd); void em_table_free(struct em_perf_table __rcu *table); int em_dev_compute_costs(struct device *dev, struct em_perf_state *table, int nr_states); +int em_dev_update_chip_binning(struct device *dev); /** * em_pd_get_efficient_state() - Get an efficient performance state from the EM @@ -387,6 +388,10 @@ int em_dev_compute_costs(struct device *dev, struct em_perf_state *table, { return -EINVAL; } +static inline int em_dev_update_chip_binning(struct device *dev) +{ + return -EINVAL; +} #endif #endif diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c index 6960dd7393b2d..1494a909844a4 100644 --- a/kernel/power/energy_model.c +++ b/kernel/power/energy_model.c @@ -808,3 +808,54 @@ static void em_update_workfn(struct work_struct *work) { em_check_capacity_update(); } + +/** + * em_dev_update_chip_binning() - Update Energy Model with new values after + * the new voltage information is present in the OPPs. + * @dev : Device for which the Energy Model has to be updated. + * + * This function allows to update easily the EM with new values available in + * the OPP framework and DT. It can be used after the chip has been properly + * verified by device drivers and the voltages adjusted for the 'chip binning'. + * It uses the "dynamic-power-coefficient" DT property to calculate the power + * values for EM. For power calculation it uses the new adjusted voltage + * values known for OPPs, which might be changed after boot. + */ +int em_dev_update_chip_binning(struct device *dev) +{ + struct em_perf_table __rcu *em_table; + struct em_perf_domain *pd; + int i, ret; + + if (IS_ERR_OR_NULL(dev)) + return -EINVAL; + + pd = em_pd_get(dev); + if (!pd) { + dev_warn(dev, "Couldn't find Energy Model %d\n", ret); + return -EINVAL; + } + + em_table = em_table_dup(pd); + if (!em_table) { + dev_warn(dev, "EM: allocation failed\n"); + return -ENOMEM; + } + + /* Update power values which might change due to new voltage in OPPs */ + for (i = 0; i < pd->nr_perf_states; i++) { + unsigned long freq = em_table->state[i].frequency; + unsigned long power; + + ret = dev_pm_opp_calc_power(dev, &power, &freq); + if (ret) { + em_table_free(em_table); + return ret; + } + + em_table->state[i].power = power; + } + + return em_recalc_and_update(dev, pd, em_table); +} +EXPORT_SYMBOL_GPL(em_dev_update_chip_binning); -- 2.25.1
There is going to be a new update function addressing chip binning. Therefore, some common code which can be refactored and called from upcoming changes and em_adjust_new_capacity(). In this way the code duplication can be avoided. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> --- kernel/power/energy_model.c | 58 +++++++++++++++++++++++++------------ 1 file changed, 39 insertions(+), 19 deletions(-) diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c index 9e1c9aa399ea9..6960dd7393b2d 100644 --- a/kernel/power/energy_model.c +++ b/kernel/power/energy_model.c @@ -674,23 +674,15 @@ void em_dev_unregister_perf_domain(struct device *dev) } EXPORT_SYMBOL_GPL(em_dev_unregister_perf_domain); -/* - * Adjustment of CPU performance values after boot, when all CPUs capacites - * are correctly calculated. - */ -static void em_adjust_new_capacity(struct device *dev, - struct em_perf_domain *pd, - u64 max_cap) +static struct em_perf_table __rcu *em_table_dup(struct em_perf_domain *pd) { struct em_perf_table __rcu *em_table; struct em_perf_state *ps, *new_ps; - int ret, ps_size; + int ps_size; em_table = em_table_alloc(pd); - if (!em_table) { - dev_warn(dev, "EM: allocation failed\n"); - return; - } + if (!em_table) + return NULL; new_ps = em_table->state; @@ -702,24 +694,52 @@ static void em_adjust_new_capacity(struct device *dev, rcu_read_unlock(); - em_init_performance(dev, pd, new_ps, pd->nr_perf_states); - ret = em_compute_costs(dev, new_ps, NULL, pd->nr_perf_states, + return em_table; +} + +static int em_recalc_and_update(struct device *dev, struct em_perf_domain *pd, + struct em_perf_table __rcu *em_table) +{ + int ret; + + ret = em_compute_costs(dev, em_table->state, NULL, pd->nr_perf_states, pd->flags); - if (ret) { - dev_warn(dev, "EM: compute costs failed\n"); - return; - } + if (ret) + goto free_em_table; ret = em_dev_update_perf_domain(dev, em_table); if (ret) - dev_warn(dev, "EM: update failed %d\n", ret); + goto free_em_table; /* * This is one-time-update, so give up the ownership in this updater. * The EM framework has incremented the usage counter and from now * will keep the reference (then free the memory when needed). */ +free_em_table: em_table_free(em_table); + return ret; +} + +/* + * Adjustment of CPU performance values after boot, when all CPUs capacites + * are correctly calculated. + */ +static void em_adjust_new_capacity(struct device *dev, + struct em_perf_domain *pd, + u64 max_cap) +{ + struct em_perf_table __rcu *em_table; + + em_table = em_table_dup(pd); + if (!em_table) { + dev_warn(dev, "EM: allocation failed\n"); + return; + } + + em_init_performance(dev, pd, em_table->state, pd->nr_perf_states); + + em_recalc_and_update(dev, pd, em_table); } static void em_check_capacity_update(void) -- 2.25.1
There are device drivers which can modify voltage values for OPPs. It could be due to the chip binning and those drivers have specific chip knowledge about it. This adjustment can happen after Energy Model is registered, thus EM can have stale data about power. Export dev_opp_pm_calc_power() which can be used by Energy Model to calculate new power with the new voltage for OPPs. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> --- drivers/opp/of.c | 17 ++++++++++++----- include/linux/pm_opp.h | 8 ++++++++ 2 files changed, 20 insertions(+), 5 deletions(-) diff --git a/drivers/opp/of.c b/drivers/opp/of.c index f9f0b22bccbb4..282eb5966fd03 100644 --- a/drivers/opp/of.c +++ b/drivers/opp/of.c @@ -1494,20 +1494,26 @@ _get_dt_power(struct device *dev, unsigned long *uW, unsigned long *kHz) return 0; } -/* - * Callback function provided to the Energy Model framework upon registration. +/** + * dev_pm_opp_calc_power() - Calculate power value for device with EM + * @dev : Device for which an Energy Model has to be registered + * @uW : New power value that is calculated + * @kHz : Frequency for which the new power is calculated + * * This computes the power estimated by @dev at @kHz if it is the frequency * of an existing OPP, or at the frequency of the first OPP above @kHz otherwise * (see dev_pm_opp_find_freq_ceil()). This function updates @kHz to the ceiled * frequency and @uW to the associated power. The power is estimated as * P = C * V^2 * f with C being the device's capacitance and V and f * respectively the voltage and frequency of the OPP. + * It is also used as a callback function provided to the Energy Model + * framework upon registration. * * Returns -EINVAL if the power calculation failed because of missing * parameters, 0 otherwise. */ -static int __maybe_unused _get_power(struct device *dev, unsigned long *uW, - unsigned long *kHz) +int dev_pm_opp_calc_power(struct device *dev, unsigned long *uW, + unsigned long *kHz) { struct dev_pm_opp *opp; struct device_node *np; @@ -1544,6 +1550,7 @@ static int __maybe_unused _get_power(struct device *dev, unsigned long *uW, return 0; } +EXPORT_SYMBOL_GPL(dev_pm_opp_calc_power); static bool _of_has_opp_microwatt_property(struct device *dev) { @@ -1619,7 +1626,7 @@ int dev_pm_opp_of_register_em(struct device *dev, struct cpumask *cpus) goto failed; } - EM_SET_ACTIVE_POWER_CB(em_cb, _get_power); + EM_SET_ACTIVE_POWER_CB(em_cb, dev_pm_opp_calc_power); register_em: ret = em_dev_register_perf_domain(dev, nr_opp, &em_cb, cpus, true); diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h index 065a47382302c..31370deb9905f 100644 --- a/include/linux/pm_opp.h +++ b/include/linux/pm_opp.h @@ -476,6 +476,8 @@ struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp); int of_get_required_opp_performance_state(struct device_node *np, int index); int dev_pm_opp_of_find_icc_paths(struct device *dev, struct opp_table *opp_table); int dev_pm_opp_of_register_em(struct device *dev, struct cpumask *cpus); +int dev_pm_opp_calc_power(struct device *dev, unsigned long *uW, + unsigned long *kHz); static inline void dev_pm_opp_of_unregister_em(struct device *dev) { em_dev_unregister_perf_domain(dev); @@ -539,6 +541,12 @@ static inline void dev_pm_opp_of_unregister_em(struct device *dev) { } +static inline int dev_pm_opp_calc_power(struct device *dev, unsigned long *uW, + unsigned long *kHz) +{ + return -EOPNOTSUPP; +} + static inline int of_get_required_opp_performance_state(struct device_node *np, int index) { return -EOPNOTSUPP; -- 2.25.1
Hi all, This is a follow-up patch aiming to add EM modification due to chip binning. The first RFC and the discussion can be found here [1]. It uses Exynos chip driver code as a 1st user. The EM framework has been extended to handle this use case easily, when the voltage has been changed after setup. On my Odroid-xu4 in some OPPs I can observe ~20% power difference. According to that data in driver tables it could be up to ~29%. This chip binning is applicable to a lot of SoCs, so the EM framework should make it easy to update. It uses the existing OPP and DT information to re-calculate the new power values. Changes: v2: - exported the OPP calculation function from the OPP/OF so it can be used from EM fwk (Viresh) - refactored EM updating function to re-use common code - added new EM function which can be used by chip device drivers which modify the voltage in OPPs v1 is at [1] Regards, Lukasz Luba [1] https://lore.kernel.org/lkml/20231220110339.1065505-1-lukasz.luba@arm.com/ Lukasz Luba (4): OPP: OF: Export dev_opp_pm_calc_power() for usage from EM PM: EM: Change the em_adjust_new_capacity() to re-use code PM: EM: Add em_dev_update_chip_binning() soc: samsung: exynos-asv: Update Energy Model after adjusting voltage drivers/opp/of.c | 17 +++-- drivers/soc/samsung/exynos-asv.c | 11 +++- include/linux/energy_model.h | 5 ++ include/linux/pm_opp.h | 8 +++ kernel/power/energy_model.c | 109 +++++++++++++++++++++++++------ 5 files changed, 125 insertions(+), 25 deletions(-) -- 2.25.1
Quoting Krzysztof Kozlowski (2024-03-12 11:50:35)
> Convert Samsung S3C6400/S3C6410 SoC clock controller bindings to DT
> schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Children of NAND controllers have only chip select, so address without the size. Correct size-cells as reported by dtbs_check: s5pv210-galaxys.dtb: onenand@b0600000: #size-cells:0:0: 0 was expected Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> --- arch/arm/boot/dts/samsung/s5pv210.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/samsung/s5pv210.dtsi b/arch/arm/boot/dts/samsung/s5pv210.dtsi index 23459430410f..9720573d84dc 100644 --- a/arch/arm/boot/dts/samsung/s5pv210.dtsi +++ b/arch/arm/boot/dts/samsung/s5pv210.dtsi @@ -82,7 +82,7 @@ onenand: nand-controller@b0600000 { clocks = <&clocks CLK_NANDXL>, <&clocks DOUT_FLASH>; clock-names = "bus", "onenand"; #address-cells = <1>; - #size-cells = <1>; + #size-cells = <0>; status = "disabled"; }; -- 2.34.1