| Message ID | 20250409-topic-smem_dramc-v1-0-94d505cd5593@oss.qualcomm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Retrieve information about DDR from SMEM | expand |
On 09/04/2025 17:47, Konrad Dybcio wrote: > SMEM allows the OS to retrieve information about the DDR memory. > Among that information, is a semi-magic value called 'HBB', or Highest > Bank address Bit, which multimedia drivers (for hardware like Adreno > and MDSS) must retrieve in order to program the IP blocks correctly. > > This series introduces an API to retrieve that value, uses it in the > aforementioned programming sequences and exposes available DDR > frequencies in debugfs (to e.g. pass to aoss_qmp debugfs). More > information can be exposed in the future, as needed. I know that for some platforms HBB differs between GPU and DPU (as it's being programmed currently). Is there a way to check, which values are we going to program: - SM6115, SM6350, SM6375 (13 vs 14) - SC8180X (15 vs 16) - QCM2290 (14 vs 15) > > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > --- > Konrad Dybcio (4): > soc: qcom: Expose DDR data from SMEM > drm/msm/a5xx: Get HBB dynamically, if available > drm/msm/a6xx: Get HBB dynamically, if available > drm/msm/mdss: Get HBB dynamically, if available > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 13 +- > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 22 ++- > drivers/gpu/drm/msm/msm_mdss.c | 35 ++++- > drivers/soc/qcom/Makefile | 3 +- > drivers/soc/qcom/smem.c | 14 +- > drivers/soc/qcom/smem.h | 9 ++ > drivers/soc/qcom/smem_dramc.c | 287 ++++++++++++++++++++++++++++++++++ > include/linux/soc/qcom/smem.h | 4 + > 8 files changed, 371 insertions(+), 16 deletions(-) > --- > base-commit: 46086739de22d72319e37c37a134d32db52e1c5c > change-id: 20250409-topic-smem_dramc-6467187ac865 > > Best regards,
On 4/9/25 5:44 PM, Dmitry Baryshkov wrote: > On 09/04/2025 17:47, Konrad Dybcio wrote: >> SMEM allows the OS to retrieve information about the DDR memory. >> Among that information, is a semi-magic value called 'HBB', or Highest >> Bank address Bit, which multimedia drivers (for hardware like Adreno >> and MDSS) must retrieve in order to program the IP blocks correctly. >> >> This series introduces an API to retrieve that value, uses it in the >> aforementioned programming sequences and exposes available DDR >> frequencies in debugfs (to e.g. pass to aoss_qmp debugfs). More >> information can be exposed in the future, as needed. > > I know that for some platforms HBB differs between GPU and DPU (as it's being programmed currently). Is there a way to check, which values are we going to program: > > - SM6115, SM6350, SM6375 (13 vs 14) > - SC8180X (15 vs 16) > - QCM2290 (14 vs 15) I believe the easiest way is to give them a smoke test. In any case, unless something is really wrong, any changes made by this patchset are supposed to be corrections Konrad
On 4/9/25 5:49 PM, Konrad Dybcio wrote: > On 4/9/25 5:44 PM, Dmitry Baryshkov wrote: >> On 09/04/2025 17:47, Konrad Dybcio wrote: >>> SMEM allows the OS to retrieve information about the DDR memory. >>> Among that information, is a semi-magic value called 'HBB', or Highest >>> Bank address Bit, which multimedia drivers (for hardware like Adreno >>> and MDSS) must retrieve in order to program the IP blocks correctly. >>> >>> This series introduces an API to retrieve that value, uses it in the >>> aforementioned programming sequences and exposes available DDR >>> frequencies in debugfs (to e.g. pass to aoss_qmp debugfs). More >>> information can be exposed in the future, as needed. >> >> I know that for some platforms HBB differs between GPU and DPU (as it's being programmed currently). Is there a way to check, which values are we going to program: >> >> - SM6115, SM6350, SM6375 (13 vs 14) SM6350 has INFO_V3 SM6375 has INFO_V3_WITH_14_FREQS >> - SC8180X (15 vs 16) So I overlooked the fact that DDR info v3 (e.g. on 8180) doesn't provide the HBB value.. Need to add some more sanity checks there. Maybe I can think up some fallback logic based on the DDR type reported. >> - QCM2290 (14 vs 15) I don't have one on hand, could you please give it a go on your RB1? I would assume both it and SM6115 also provide v3 though.. Konrad
On Fri, 11 Apr 2025 at 12:49, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote: > > On 4/9/25 5:49 PM, Konrad Dybcio wrote: > > On 4/9/25 5:44 PM, Dmitry Baryshkov wrote: > >> On 09/04/2025 17:47, Konrad Dybcio wrote: > >>> SMEM allows the OS to retrieve information about the DDR memory. > >>> Among that information, is a semi-magic value called 'HBB', or Highest > >>> Bank address Bit, which multimedia drivers (for hardware like Adreno > >>> and MDSS) must retrieve in order to program the IP blocks correctly. > >>> > >>> This series introduces an API to retrieve that value, uses it in the > >>> aforementioned programming sequences and exposes available DDR > >>> frequencies in debugfs (to e.g. pass to aoss_qmp debugfs). More > >>> information can be exposed in the future, as needed. > >> > >> I know that for some platforms HBB differs between GPU and DPU (as it's being programmed currently). Is there a way to check, which values are we going to program: > >> > >> - SM6115, SM6350, SM6375 (13 vs 14) > > SM6350 has INFO_V3 > SM6375 has INFO_V3_WITH_14_FREQS I'm not completely sure what you mean here. I pointed out that these platforms disagreed upon the HBB value between the DPU/msm_mdss.c and a6xx_gpu.c. In some cases (a610/SM6115 and a619/SM6350) that was intentional to fix screen corruption issues. I don't remember if it was the case for QCM2290 or not. > > >> - SC8180X (15 vs 16) > > So I overlooked the fact that DDR info v3 (e.g. on 8180) doesn't provide > the HBB value.. Need to add some more sanity checks there. > > Maybe I can think up some fallback logic based on the DDR type reported. > > >> - QCM2290 (14 vs 15) > > I don't have one on hand, could you please give it a go on your RB1? > I would assume both it and SM6115 also provide v3 though.. > > Konrad
On 4/11/25 11:57 AM, Dmitry Baryshkov wrote: > On Fri, 11 Apr 2025 at 12:49, Konrad Dybcio > <konrad.dybcio@oss.qualcomm.com> wrote: >> >> On 4/9/25 5:49 PM, Konrad Dybcio wrote: >>> On 4/9/25 5:44 PM, Dmitry Baryshkov wrote: >>>> On 09/04/2025 17:47, Konrad Dybcio wrote: >>>>> SMEM allows the OS to retrieve information about the DDR memory. >>>>> Among that information, is a semi-magic value called 'HBB', or Highest >>>>> Bank address Bit, which multimedia drivers (for hardware like Adreno >>>>> and MDSS) must retrieve in order to program the IP blocks correctly. >>>>> >>>>> This series introduces an API to retrieve that value, uses it in the >>>>> aforementioned programming sequences and exposes available DDR >>>>> frequencies in debugfs (to e.g. pass to aoss_qmp debugfs). More >>>>> information can be exposed in the future, as needed. >>>> >>>> I know that for some platforms HBB differs between GPU and DPU (as it's being programmed currently). Is there a way to check, which values are we going to program: >>>> >>>> - SM6115, SM6350, SM6375 (13 vs 14) >> >> SM6350 has INFO_V3 >> SM6375 has INFO_V3_WITH_14_FREQS > > I'm not completely sure what you mean here. I pointed out that these > platforms disagreed upon the HBB value between the DPU/msm_mdss.c and > a6xx_gpu.c. > In some cases (a610/SM6115 and a619/SM6350) that was intentional to > fix screen corruption issues. I don't remember if it was the case for > QCM2290 or not. As I said below, I couldn't get a good answer yet, as the magic value is not provided explicitly and I'll hopefully be able to derive it from the available data Konrad > >> >>>> - SC8180X (15 vs 16) >> >> So I overlooked the fact that DDR info v3 (e.g. on 8180) doesn't provide >> the HBB value.. Need to add some more sanity checks there. >> >> Maybe I can think up some fallback logic based on the DDR type reported. >> >>>> - QCM2290 (14 vs 15) >> >> I don't have one on hand, could you please give it a go on your RB1? >> I would assume both it and SM6115 also provide v3 though.. >> >> Konrad > > >
On Fri, Apr 11, 2025 at 12:03:03PM +0200, Konrad Dybcio wrote: > On 4/11/25 11:57 AM, Dmitry Baryshkov wrote: > > On Fri, 11 Apr 2025 at 12:49, Konrad Dybcio > > <konrad.dybcio@oss.qualcomm.com> wrote: > >> > >> On 4/9/25 5:49 PM, Konrad Dybcio wrote: > >>> On 4/9/25 5:44 PM, Dmitry Baryshkov wrote: > >>>> On 09/04/2025 17:47, Konrad Dybcio wrote: > >>>>> SMEM allows the OS to retrieve information about the DDR memory. > >>>>> Among that information, is a semi-magic value called 'HBB', or Highest > >>>>> Bank address Bit, which multimedia drivers (for hardware like Adreno > >>>>> and MDSS) must retrieve in order to program the IP blocks correctly. > >>>>> > >>>>> This series introduces an API to retrieve that value, uses it in the > >>>>> aforementioned programming sequences and exposes available DDR > >>>>> frequencies in debugfs (to e.g. pass to aoss_qmp debugfs). More > >>>>> information can be exposed in the future, as needed. > >>>> > >>>> I know that for some platforms HBB differs between GPU and DPU (as it's being programmed currently). Is there a way to check, which values are we going to program: > >>>> > >>>> - SM6115, SM6350, SM6375 (13 vs 14) > >> > >> SM6350 has INFO_V3 > >> SM6375 has INFO_V3_WITH_14_FREQS > > > > I'm not completely sure what you mean here. I pointed out that these > > platforms disagreed upon the HBB value between the DPU/msm_mdss.c and > > a6xx_gpu.c. > > In some cases (a610/SM6115 and a619/SM6350) that was intentional to > > fix screen corruption issues. I don't remember if it was the case for > > QCM2290 or not. > > As I said below, I couldn't get a good answer yet, as the magic value > is not provided explicitly and I'll hopefully be able to derive it from > the available data I see... Is this data even supposed to be poked into? The foo_WITH_bar types doesn't sound like a very stable API. > > Konrad > > > > >> > >>>> - SC8180X (15 vs 16) > >> > >> So I overlooked the fact that DDR info v3 (e.g. on 8180) doesn't provide > >> the HBB value.. Need to add some more sanity checks there. > >> > >> Maybe I can think up some fallback logic based on the DDR type reported. > >> > >>>> - QCM2290 (14 vs 15) > >> > >> I don't have one on hand, could you please give it a go on your RB1? > >> I would assume both it and SM6115 also provide v3 though.. > >> > >> Konrad > > > > > >
On 4/11/25 12:50 PM, Dmitry Baryshkov wrote: > On Fri, Apr 11, 2025 at 12:03:03PM +0200, Konrad Dybcio wrote: >> On 4/11/25 11:57 AM, Dmitry Baryshkov wrote: >>> On Fri, 11 Apr 2025 at 12:49, Konrad Dybcio >>> <konrad.dybcio@oss.qualcomm.com> wrote: >>>> >>>> On 4/9/25 5:49 PM, Konrad Dybcio wrote: >>>>> On 4/9/25 5:44 PM, Dmitry Baryshkov wrote: >>>>>> On 09/04/2025 17:47, Konrad Dybcio wrote: >>>>>>> SMEM allows the OS to retrieve information about the DDR memory. >>>>>>> Among that information, is a semi-magic value called 'HBB', or Highest >>>>>>> Bank address Bit, which multimedia drivers (for hardware like Adreno >>>>>>> and MDSS) must retrieve in order to program the IP blocks correctly. >>>>>>> >>>>>>> This series introduces an API to retrieve that value, uses it in the >>>>>>> aforementioned programming sequences and exposes available DDR >>>>>>> frequencies in debugfs (to e.g. pass to aoss_qmp debugfs). More >>>>>>> information can be exposed in the future, as needed. >>>>>> >>>>>> I know that for some platforms HBB differs between GPU and DPU (as it's being programmed currently). Is there a way to check, which values are we going to program: >>>>>> >>>>>> - SM6115, SM6350, SM6375 (13 vs 14) >>>> >>>> SM6350 has INFO_V3 >>>> SM6375 has INFO_V3_WITH_14_FREQS >>> >>> I'm not completely sure what you mean here. I pointed out that these >>> platforms disagreed upon the HBB value between the DPU/msm_mdss.c and >>> a6xx_gpu.c. >>> In some cases (a610/SM6115 and a619/SM6350) that was intentional to >>> fix screen corruption issues. I don't remember if it was the case for >>> QCM2290 or not. >> >> As I said below, I couldn't get a good answer yet, as the magic value >> is not provided explicitly and I'll hopefully be able to derive it from >> the available data > > I see... > Is this data even supposed to be poked into? The foo_WITH_bar types > doesn't sound like a very stable API. Yeah, it was designed with both the producer and consumer being part of a single codebase, always having the data structures in sync.. Konrad
On Fri, Apr 11, 2025 at 12:52:32PM +0200, Konrad Dybcio wrote: > On 4/11/25 12:50 PM, Dmitry Baryshkov wrote: > > On Fri, Apr 11, 2025 at 12:03:03PM +0200, Konrad Dybcio wrote: > >> On 4/11/25 11:57 AM, Dmitry Baryshkov wrote: > >>> On Fri, 11 Apr 2025 at 12:49, Konrad Dybcio > >>> <konrad.dybcio@oss.qualcomm.com> wrote: > >>>> > >>>> On 4/9/25 5:49 PM, Konrad Dybcio wrote: > >>>>> On 4/9/25 5:44 PM, Dmitry Baryshkov wrote: > >>>>>> On 09/04/2025 17:47, Konrad Dybcio wrote: > >>>>>>> SMEM allows the OS to retrieve information about the DDR memory. > >>>>>>> Among that information, is a semi-magic value called 'HBB', or Highest > >>>>>>> Bank address Bit, which multimedia drivers (for hardware like Adreno > >>>>>>> and MDSS) must retrieve in order to program the IP blocks correctly. > >>>>>>> > >>>>>>> This series introduces an API to retrieve that value, uses it in the > >>>>>>> aforementioned programming sequences and exposes available DDR > >>>>>>> frequencies in debugfs (to e.g. pass to aoss_qmp debugfs). More > >>>>>>> information can be exposed in the future, as needed. > >>>>>> > >>>>>> I know that for some platforms HBB differs between GPU and DPU (as it's being programmed currently). Is there a way to check, which values are we going to program: > >>>>>> > >>>>>> - SM6115, SM6350, SM6375 (13 vs 14) > >>>> > >>>> SM6350 has INFO_V3 > >>>> SM6375 has INFO_V3_WITH_14_FREQS > >>> > >>> I'm not completely sure what you mean here. I pointed out that these > >>> platforms disagreed upon the HBB value between the DPU/msm_mdss.c and > >>> a6xx_gpu.c. > >>> In some cases (a610/SM6115 and a619/SM6350) that was intentional to > >>> fix screen corruption issues. I don't remember if it was the case for > >>> QCM2290 or not. > >> > >> As I said below, I couldn't get a good answer yet, as the magic value > >> is not provided explicitly and I'll hopefully be able to derive it from > >> the available data > > > > I see... > > Is this data even supposed to be poked into? The foo_WITH_bar types > > doesn't sound like a very stable API. > > Yeah, it was designed with both the producer and consumer being part > of a single codebase, always having the data structures in sync.. I feel somewhat worried about parsing those structures then. But... the only viable alternative is to have an in-kernel list of possible platform configurations and parse the /memory@foo/ddr_device_type property.
On 4/14/25 2:28 PM, Dmitry Baryshkov wrote: > On Fri, Apr 11, 2025 at 12:52:32PM +0200, Konrad Dybcio wrote: >> On 4/11/25 12:50 PM, Dmitry Baryshkov wrote: >>> On Fri, Apr 11, 2025 at 12:03:03PM +0200, Konrad Dybcio wrote: >>>> On 4/11/25 11:57 AM, Dmitry Baryshkov wrote: >>>>> On Fri, 11 Apr 2025 at 12:49, Konrad Dybcio >>>>> <konrad.dybcio@oss.qualcomm.com> wrote: >>>>>> >>>>>> On 4/9/25 5:49 PM, Konrad Dybcio wrote: >>>>>>> On 4/9/25 5:44 PM, Dmitry Baryshkov wrote: >>>>>>>> On 09/04/2025 17:47, Konrad Dybcio wrote: >>>>>>>>> SMEM allows the OS to retrieve information about the DDR memory. >>>>>>>>> Among that information, is a semi-magic value called 'HBB', or Highest >>>>>>>>> Bank address Bit, which multimedia drivers (for hardware like Adreno >>>>>>>>> and MDSS) must retrieve in order to program the IP blocks correctly. >>>>>>>>> >>>>>>>>> This series introduces an API to retrieve that value, uses it in the >>>>>>>>> aforementioned programming sequences and exposes available DDR >>>>>>>>> frequencies in debugfs (to e.g. pass to aoss_qmp debugfs). More >>>>>>>>> information can be exposed in the future, as needed. >>>>>>>> >>>>>>>> I know that for some platforms HBB differs between GPU and DPU (as it's being programmed currently). Is there a way to check, which values are we going to program: >>>>>>>> >>>>>>>> - SM6115, SM6350, SM6375 (13 vs 14) >>>>>> >>>>>> SM6350 has INFO_V3 >>>>>> SM6375 has INFO_V3_WITH_14_FREQS >>>>> >>>>> I'm not completely sure what you mean here. I pointed out that these >>>>> platforms disagreed upon the HBB value between the DPU/msm_mdss.c and >>>>> a6xx_gpu.c. >>>>> In some cases (a610/SM6115 and a619/SM6350) that was intentional to >>>>> fix screen corruption issues. I don't remember if it was the case for >>>>> QCM2290 or not. >>>> >>>> As I said below, I couldn't get a good answer yet, as the magic value >>>> is not provided explicitly and I'll hopefully be able to derive it from >>>> the available data >>> >>> I see... >>> Is this data even supposed to be poked into? The foo_WITH_bar types >>> doesn't sound like a very stable API. >> >> Yeah, it was designed with both the producer and consumer being part >> of a single codebase, always having the data structures in sync.. > > I feel somewhat worried about parsing those structures then. But... the > only viable alternative is to have an in-kernel list of possible > platform configurations and parse the /memory@foo/ddr_device_type > property. Well, this is where that property's value comes from.. Konrad
SMEM allows the OS to retrieve information about the DDR memory. Among that information, is a semi-magic value called 'HBB', or Highest Bank address Bit, which multimedia drivers (for hardware like Adreno and MDSS) must retrieve in order to program the IP blocks correctly. This series introduces an API to retrieve that value, uses it in the aforementioned programming sequences and exposes available DDR frequencies in debugfs (to e.g. pass to aoss_qmp debugfs). More information can be exposed in the future, as needed. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> --- Konrad Dybcio (4): soc: qcom: Expose DDR data from SMEM drm/msm/a5xx: Get HBB dynamically, if available drm/msm/a6xx: Get HBB dynamically, if available drm/msm/mdss: Get HBB dynamically, if available drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 13 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 22 ++- drivers/gpu/drm/msm/msm_mdss.c | 35 ++++- drivers/soc/qcom/Makefile | 3 +- drivers/soc/qcom/smem.c | 14 +- drivers/soc/qcom/smem.h | 9 ++ drivers/soc/qcom/smem_dramc.c | 287 ++++++++++++++++++++++++++++++++++ include/linux/soc/qcom/smem.h | 4 + 8 files changed, 371 insertions(+), 16 deletions(-) --- base-commit: 46086739de22d72319e37c37a134d32db52e1c5c change-id: 20250409-topic-smem_dramc-6467187ac865 Best regards,