Re: [PATCH] drm/bridge: adv7511: Fix Intermittent EDID failures
On Mon, May 20, 2024 at 8:16 PM Adam Ford wrote:
>
> In the process of adding support for shared IRQ pins, a scenario
> was accidentally created where adv7511_irq_process returned
> prematurely causing the EDID to fail randomly.
>
> Since the interrupt handler is broken up into two main helper functions,
> update both of them to treat the helper functions as IRQ handlers. These
> IRQ routines process their respective tasks as before, but if they
> determine that actual work was done, mark the respective IRQ status
> accordingly, and delay the check until everything has been processed.
>
> This should guarantee the helper functions don't return prematurely
> while still returning proper values of either IRQ_HANDLED or IRQ_NONE.
>
> Reported by: Liu Ying
> Fixes: f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
> Signed-off-by: Adam Ford
+ Liu
Sorry about the e-mail address copy-paste error.
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> index ea271f62b214..ec0b7f3d889c 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -401,7 +401,7 @@ struct adv7511 {
>
> #ifdef CONFIG_DRM_I2C_ADV7511_CEC
> int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511);
> -void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
> +int adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
> #else
> static inline int adv7511_cec_init(struct device *dev, struct adv7511
> *adv7511)
> {
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> index 44451a9658a3..4efb2cabf1b5 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> @@ -119,7 +119,7 @@ static void adv7511_cec_rx(struct adv7511 *adv7511, int
> rx_buf)
> cec_received_msg(adv7511->cec_adap, );
> }
>
> -void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1)
> +int adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1)
> {
> unsigned int offset = adv7511->info->reg_cec_offset;
> const u32 irq_tx_mask = ADV7511_INT1_CEC_TX_READY |
> @@ -130,17 +130,21 @@ void adv7511_cec_irq_process(struct adv7511 *adv7511,
> unsigned int irq1)
> ADV7511_INT1_CEC_RX_READY3;
> unsigned int rx_status;
> int rx_order[3] = { -1, -1, -1 };
> - int i;
> + int i, ret = 0;
> + int irq_status = IRQ_NONE;
>
> - if (irq1 & irq_tx_mask)
> + if (irq1 & irq_tx_mask) {
> adv_cec_tx_raw_status(adv7511, irq1);
> + irq_status = IRQ_HANDLED;
> + }
>
> if (!(irq1 & irq_rx_mask))
> - return;
> + return irq_status;
>
> - if (regmap_read(adv7511->regmap_cec,
> - ADV7511_REG_CEC_RX_STATUS + offset, _status))
> - return;
> + ret = regmap_read(adv7511->regmap_cec,
> + ADV7511_REG_CEC_RX_STATUS + offset, _status);
> + if (ret < 0)
> + return ret;
>
> /*
> * ADV7511_REG_CEC_RX_STATUS[5:0] contains the reception order of RX
> @@ -172,6 +176,8 @@ void adv7511_cec_irq_process(struct adv7511 *adv7511,
> unsigned int irq1)
>
> adv7511_cec_rx(adv7511, rx_buf);
> }
> +
> + return IRQ_HANDLED;
> }
>
> static int adv7511_cec_adap_enable(struct cec_adapter *adap, bool enable)
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 66ccb61e2a66..56dd2d5a0376 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -469,6 +469,8 @@ static int adv7511_irq_process(struct adv7511 *adv7511,
> bool process_hpd)
> {
> unsigned int irq0, irq1;
> int ret;
> + int cec_status;
> + int irq_status = IRQ_NONE;
>
> ret = regmap_read(adv7511->regmap, ADV7511_REG_INT(0), );
> if (ret < 0)
> @@ -478,38 +480,41 @@ static int adv7511_irq_process(struct adv7511 *adv7511,
> bool process_hpd)
> if (ret < 0)
> return ret;
>
> - /* If there is no IRQ to handle, exit indicating no IRQ data */
> - if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
> - !(irq1 & ADV7511_INT1_DDC_ERROR))
> - return -ENODATA;
> -
> regmap_write(adv7511->regmap, ADV7511_RE
Re: [PATCH] drm/bridge: adv7511: Exit interrupt handling when necessary
On Mon, May 20, 2024 at 4:16 PM Dmitry Baryshkov
wrote:
>
> On Mon, May 20, 2024 at 07:46:05AM -0500, Adam Ford wrote:
> > On Mon, May 20, 2024 at 7:00 AM Dmitry Baryshkov
> > wrote:
> > >
> > > On Mon, 20 May 2024 at 14:48, Sui Jingfeng wrote:
> > > >
> > > > Hi,
> > > >
> > > >
> > > > On 5/20/24 19:13, Dmitry Baryshkov wrote:
> > > > > On Mon, 20 May 2024 at 14:11, Sui Jingfeng
> > > > > wrote:
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> On 5/20/24 06:11, Dmitry Baryshkov wrote:
> > > > >>> On Thu, May 16, 2024 at 06:10:06PM +0800, Liu Ying wrote:
> > > > >>>> Commit f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO
> > > > >>>> pins")
> > > > >>>> fails to consider the case where adv7511->i2c_main->irq is zero,
> > > > >>>> i.e.,
> > > > >>>> no interrupt requested at all.
> > > > >>>>
> > > > >>>> Without interrupt, adv7511_wait_for_edid() could return -EIO
> > > > >>>> sometimes,
> > > > >>>> because it polls adv7511->edid_read flag by calling
> > > > >>>> adv7511_irq_process()
> > > > >>>> a few times, but adv7511_irq_process() happens to refuse to handle
> > > > >>>> interrupt by returning -ENODATA. Hence, EDID retrieval fails
> > > > >>>> randomly.
> >
> > Sorry about that. I did some testing and didn't see any regressions,
> > but if it was random, it's likely I just was lucky to not see it.
> >
> > > > >>>>
> > > > >>>> Fix the issue by checking adv7511->i2c_main->irq before exiting
> > > > >>>> interrupt
> > > > >>>> handling from adv7511_irq_process().
> > > > >>>>
> > > > >>>> Fixes: f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO
> > > > >>>> pins")
> > > > >>>> Signed-off-by: Liu Ying
> > > > >>>> ---
> > > > >>>>drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 3 ++-
> > > > >>>>1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >>>>
> > > > >>>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > > >>>> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > > >>>> index 6089b0bb9321..2074fa3c1b7b 100644
> > > > >>>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > > >>>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > > >>>> @@ -479,7 +479,8 @@ static int adv7511_irq_process(struct adv7511
> > > > >>>> *adv7511, bool process_hpd)
> > > > >>>> return ret;
> > > > >>>>
> > > > >>>> /* If there is no IRQ to handle, exit indicating no IRQ data
> > > > >>>> */
> > > > >>>> -if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
> > > > >>>> +if (adv7511->i2c_main->irq &&
> > > > >>>> +!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
> > > > >>>> !(irq1 & ADV7511_INT1_DDC_ERROR))
> > > > >>>> return -ENODATA;
> > > > >>>
> > > > >>> I think it might be better to handle -ENODATA in
> > > > >>> adv7511_wait_for_edid()
> > > > >>> instead. WDYT?
> > > > >>>
> > > > >>
> > > > >> I think this is may deserve another patch.
> > > > >
> > > > > My point is that the IRQ handler is fine to remove -ENODATA here,
> > > >
> > > > [...]
> > > >
> > > > > there is no pending IRQ that can be handled.
> > > >
> > > > But there may has other things need to do in the adv7511_irq_process()
> > > > function.
> > >
> > > But the function returns anyway. So, we know that the condition is broken.
> >
> > When I originally submitted the patch, I only added the shared IRQ
> > flag wi
[PATCH] drm/bridge: adv7511: Fix Intermittent EDID failures
In the process of adding support for shared IRQ pins, a scenario
was accidentally created where adv7511_irq_process returned
prematurely causing the EDID to fail randomly.
Since the interrupt handler is broken up into two main helper functions,
update both of them to treat the helper functions as IRQ handlers. These
IRQ routines process their respective tasks as before, but if they
determine that actual work was done, mark the respective IRQ status
accordingly, and delay the check until everything has been processed.
This should guarantee the helper functions don't return prematurely
while still returning proper values of either IRQ_HANDLED or IRQ_NONE.
Reported by: Liu Ying
Fixes: f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
Signed-off-by: Adam Ford
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index ea271f62b214..ec0b7f3d889c 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -401,7 +401,7 @@ struct adv7511 {
#ifdef CONFIG_DRM_I2C_ADV7511_CEC
int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511);
-void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
+int adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
#else
static inline int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511)
{
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
index 44451a9658a3..4efb2cabf1b5 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
@@ -119,7 +119,7 @@ static void adv7511_cec_rx(struct adv7511 *adv7511, int
rx_buf)
cec_received_msg(adv7511->cec_adap, );
}
-void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1)
+int adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1)
{
unsigned int offset = adv7511->info->reg_cec_offset;
const u32 irq_tx_mask = ADV7511_INT1_CEC_TX_READY |
@@ -130,17 +130,21 @@ void adv7511_cec_irq_process(struct adv7511 *adv7511,
unsigned int irq1)
ADV7511_INT1_CEC_RX_READY3;
unsigned int rx_status;
int rx_order[3] = { -1, -1, -1 };
- int i;
+ int i, ret = 0;
+ int irq_status = IRQ_NONE;
- if (irq1 & irq_tx_mask)
+ if (irq1 & irq_tx_mask) {
adv_cec_tx_raw_status(adv7511, irq1);
+ irq_status = IRQ_HANDLED;
+ }
if (!(irq1 & irq_rx_mask))
- return;
+ return irq_status;
- if (regmap_read(adv7511->regmap_cec,
- ADV7511_REG_CEC_RX_STATUS + offset, _status))
- return;
+ ret = regmap_read(adv7511->regmap_cec,
+ ADV7511_REG_CEC_RX_STATUS + offset, _status);
+ if (ret < 0)
+ return ret;
/*
* ADV7511_REG_CEC_RX_STATUS[5:0] contains the reception order of RX
@@ -172,6 +176,8 @@ void adv7511_cec_irq_process(struct adv7511 *adv7511,
unsigned int irq1)
adv7511_cec_rx(adv7511, rx_buf);
}
+
+ return IRQ_HANDLED;
}
static int adv7511_cec_adap_enable(struct cec_adapter *adap, bool enable)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 66ccb61e2a66..56dd2d5a0376 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -469,6 +469,8 @@ static int adv7511_irq_process(struct adv7511 *adv7511,
bool process_hpd)
{
unsigned int irq0, irq1;
int ret;
+ int cec_status;
+ int irq_status = IRQ_NONE;
ret = regmap_read(adv7511->regmap, ADV7511_REG_INT(0), );
if (ret < 0)
@@ -478,38 +480,41 @@ static int adv7511_irq_process(struct adv7511 *adv7511,
bool process_hpd)
if (ret < 0)
return ret;
- /* If there is no IRQ to handle, exit indicating no IRQ data */
- if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
- !(irq1 & ADV7511_INT1_DDC_ERROR))
- return -ENODATA;
-
regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0);
regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
- if (process_hpd && irq0 & ADV7511_INT0_HPD && adv7511->bridge.encoder)
+ if (process_hpd && irq0 & ADV7511_INT0_HPD && adv7511->bridge.encoder) {
schedule_work(>hpd_work);
+ irq_status = IRQ_HANDLED;
+ }
if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
adv7511->edid_read = true;
if (adv7511->i2c_main->irq)
wake_up_all(>wq);
+ irq_status = IRQ_HANDLED;
Re: [PATCH] drm/bridge: adv7511: Exit interrupt handling when necessary
On Mon, May 20, 2024 at 7:00 AM Dmitry Baryshkov
wrote:
>
> On Mon, 20 May 2024 at 14:48, Sui Jingfeng wrote:
> >
> > Hi,
> >
> >
> > On 5/20/24 19:13, Dmitry Baryshkov wrote:
> > > On Mon, 20 May 2024 at 14:11, Sui Jingfeng wrote:
> > >>
> > >> Hi,
> > >>
> > >> On 5/20/24 06:11, Dmitry Baryshkov wrote:
> > >>> On Thu, May 16, 2024 at 06:10:06PM +0800, Liu Ying wrote:
> > Commit f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO
> > pins")
> > fails to consider the case where adv7511->i2c_main->irq is zero, i.e.,
> > no interrupt requested at all.
> >
> > Without interrupt, adv7511_wait_for_edid() could return -EIO sometimes,
> > because it polls adv7511->edid_read flag by calling
> > adv7511_irq_process()
> > a few times, but adv7511_irq_process() happens to refuse to handle
> > interrupt by returning -ENODATA. Hence, EDID retrieval fails randomly.
Sorry about that. I did some testing and didn't see any regressions,
but if it was random, it's likely I just was lucky to not see it.
> >
> > Fix the issue by checking adv7511->i2c_main->irq before exiting
> > interrupt
> > handling from adv7511_irq_process().
> >
> > Fixes: f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO
> > pins")
> > Signed-off-by: Liu Ying
> > ---
> > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > index 6089b0bb9321..2074fa3c1b7b 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > @@ -479,7 +479,8 @@ static int adv7511_irq_process(struct adv7511
> > *adv7511, bool process_hpd)
> > return ret;
> >
> > /* If there is no IRQ to handle, exit indicating no IRQ data */
> > -if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
> > +if (adv7511->i2c_main->irq &&
> > +!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
> > !(irq1 & ADV7511_INT1_DDC_ERROR))
> > return -ENODATA;
> > >>>
> > >>> I think it might be better to handle -ENODATA in adv7511_wait_for_edid()
> > >>> instead. WDYT?
> > >>>
> > >>
> > >> I think this is may deserve another patch.
> > >
> > > My point is that the IRQ handler is fine to remove -ENODATA here,
> >
> > [...]
> >
> > > there is no pending IRQ that can be handled.
> >
> > But there may has other things need to do in the adv7511_irq_process()
> > function.
>
> But the function returns anyway. So, we know that the condition is broken.
When I originally submitted the patch, I only added the shared IRQ
flag without any IRQ condition checks, IRQ because I didn't want to
break anything. The feedback I got was to check to see if the IRQ was
intended by the device. My focus was the adv7511_drv.c file because
that appears to be what the registered IRQ hander was, but after
looking through adv7511_cec, I see that adv7511_cec_irq_process checks
adv_cec_tx_raw_status and returns if there is nothing to do.
Would it make sense to move the if statement did the following things:
- Make adv7511_cec_irq_process return an int and modify it to return
0 in normal operation or return -ENODATA where there is nothing to do.
It already has the checks in place to determine if there is work to
do, so the impact here should be minimal.
- Move the check I added on whether or not there is an interrupt to
the very end of adv7511_irq_process just before the return 0.
- Instead of blindly returning 0, modify the if statement to read the
state of the return code of adv7511_cec_irq_process and the IRQ flags
it already checks. If ADV7511_INT0_HPD, ADV7511_INT0_EDID_READY and
ADV7511_INT1_DDC_ERROR are all not true and adv7511_cec_irq_process
returned early, return ENODATA, but if any of the interrupts was
present and adv7511_cec_irq_process did work, it would return 0.
I think that would cover the situation where adv7511_cec_irq_process
would get called, and also prevent a false return of the IRQ being
handled when this part didn't handle anything.
It would look something like:
cec_irq = adv7511_cec_irq_process(adv7511, irq1);
/* If there is no IRQ to handle, exit indicating no IRQ data */)
if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
!(irq1 & ADV7511_INT1_DDC_ERROR) &&
cec_irq == -ENODATA)
return -ENODATA;
else
return 0
OR...
Another alternative to all this is to modify the check that I added to
verify all the following flags which are currently checked in
adv7511_cec_irq_process :
ADV7511_INT1_CEC_TX_READY
ADV7511_INT1_CEC_TX_ARBIT_LOST
ADV7511_INT1_CEC_TX_RETRY_TIMEOUT
ADV7511_INT1_CEC_RX_READY1
ADV7511_INT1_CEC_RX_READY2
ADV7511_INT1_CEC_RX_READY3
It
Re: [PATCH] drm/bridge: adv7511: Exit interrupt handling when necessary
On Thu, May 16, 2024 at 5:01 AM Liu Ying wrote:
>
> Commit f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
> fails to consider the case where adv7511->i2c_main->irq is zero, i.e.,
> no interrupt requested at all.
Sorry about that.
>
> Without interrupt, adv7511_wait_for_edid() could return -EIO sometimes,
> because it polls adv7511->edid_read flag by calling adv7511_irq_process()
> a few times, but adv7511_irq_process() happens to refuse to handle
> interrupt by returning -ENODATA. Hence, EDID retrieval fails randomly.
>
> Fix the issue by checking adv7511->i2c_main->irq before exiting interrupt
> handling from adv7511_irq_process().
>
> Fixes: f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
> Signed-off-by: Liu Ying
Acked-by: Adam Ford
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 6089b0bb9321..2074fa3c1b7b 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -479,7 +479,8 @@ static int adv7511_irq_process(struct adv7511 *adv7511,
> bool process_hpd)
> return ret;
>
> /* If there is no IRQ to handle, exit indicating no IRQ data */
> - if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
> + if (adv7511->i2c_main->irq &&
> + !(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
> !(irq1 & ADV7511_INT1_DDC_ERROR))
> return -ENODATA;
>
> --
> 2.37.1
>
Re: [PATCH V2 2/2] arm64: dts: imx8mp-beacon-kit: Enable HDMI bridge HPD
On Tue, Apr 16, 2024 at 4:18 PM Adam Ford wrote:
>
> On Mon, Mar 4, 2024 at 6:49 PM Adam Ford wrote:
> >
> > The DSI to HDMI bridge supports hot-plut-detect, but the
> > driver didn't previously support a shared IRQ GPIO. With
> > the driver updated, the interrupt can be added to the bridge.
> >
> > Signed-off-by: Adam Ford
> > Reviewed-by: Laurent Pinchart
>
> Shawn,
>
> Patch 1/2 has been applied and sits in linux-next. Are you OK to
> apply this to the IMX branch so the hot-plug detection can work?
Shawn,
Do you want me to repost this patch separately since patch 1/2 has
already been applied?
adam
>
> Thank you,
>
> adam
>
> adam
> > ---
> > V2: No Change
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
> > b/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
> > index a08057410bde..fba8fd04398d 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
> > @@ -304,6 +304,8 @@ adv_bridge: hdmi@3d {
> > compatible = "adi,adv7535";
> > reg = <0x3d>, <0x3c>, <0x3e>, <0x3f>;
> > reg-names = "main", "cec", "edid", "packet";
> > + interrupt-parent = <>;
> > + interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
> > adi,dsi-lanes = <4>;
> > #sound-dai-cells = <0>;
> >
> > --
> > 2.43.0
> >
Re: [PATCH V2 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding
On Thu, Apr 25, 2024 at 4:19 AM Marek Szyprowski
wrote:
>
> On 12.02.2024 00:09, Adam Ford wrote:
> > When using video sync pulses, the HFP, HBP, and HSA are divided between
> > the available lanes if there is more than one lane. For certain
> > timings and lane configurations, the HFP may not be evenly divisible.
> > If the HFP is rounded down, it ends up being too small which can cause
> > some monitors to not sync properly. In these instances, adjust htotal
> > and hsync to round the HFP up, and recalculate the htotal.
> >
> > Tested-by: Frieder Schrempf # Kontron BL
> > i.MX8MM with HDMI monitor
> > Signed-off-by: Adam Ford
>
> Tested-by: Marek Szyprowski
Thank you very much for testing!
>
> > ---
> > V2: No changes
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> > b/drivers/gpu/drm/bridge/samsung-dsim.c
> > index 8476650c477c..52939211fe93 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -1606,6 +1606,27 @@ static int samsung_dsim_atomic_check(struct
> > drm_bridge *bridge,
> > adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
> > DRM_MODE_FLAG_PVSYNC);
> > }
> >
> > + /*
> > + * When using video sync pulses, the HFP, HBP, and HSA are divided
> > between
> > + * the available lanes if there is more than one lane. For certain
> > + * timings and lane configurations, the HFP may not be evenly
> > divisible.
> > + * If the HFP is rounded down, it ends up being too small which can
> > cause
> > + * some monitors to not sync properly. In these instances, adjust
> > htotal
> > + * and hsync to round the HFP up, and recalculate the htotal. Through
> > trial
> > + * and error, it appears that the HBP and HSA do not appearto need
> > the same
> > + * correction that HFP does.
> > + */
> > + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes >
> > 1) {
Frieder & Marek S,
Marek V is proposing we eliminate the check against the flags and do
it unconditionally. If I send you both a different patch, would you
be willing to try them on your platforms? I don't want to risk
breaking a board.
I used the check above from the NXP downstream kernel, so it felt
safe, but I am not as familiar with the different DSI modes, so I am
not sure what the impact would be if this read:
if (dsi->lanes > 1) {
Does anyone else have an opinion on this?
> > + int hfp = adjusted_mode->hsync_start -
> > adjusted_mode->hdisplay;
> > + int remainder = hfp % dsi->lanes;
> > +
> > + if (remainder) {
> > + adjusted_mode->hsync_start += remainder;
> > + adjusted_mode->hsync_end += remainder;
> > + adjusted_mode->htotal += remainder;
> > + }
> > + }
> > +
> > return 0;
> > }
> >
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R Institute Poland
>
Re: [PATCH V2 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding
On Mon, Apr 22, 2024 at 8:01 AM Marek Vasut wrote:
>
> On 4/22/24 2:09 PM, Adam Ford wrote:
> > On Sun, Apr 21, 2024 at 9:36 AM Marek Vasut wrote:
> >>
> >> On 2/12/24 12:09 AM, Adam Ford wrote:
> >>> When using video sync pulses, the HFP, HBP, and HSA are divided between
> >>> the available lanes if there is more than one lane. For certain
> >>> timings and lane configurations, the HFP may not be evenly divisible.
> >>> If the HFP is rounded down, it ends up being too small which can cause
> >>> some monitors to not sync properly. In these instances, adjust htotal
> >>> and hsync to round the HFP up, and recalculate the htotal.
> >>>
> >>> Tested-by: Frieder Schrempf # Kontron BL
> >>> i.MX8MM with HDMI monitor
> >>> Signed-off-by: Adam Ford
> >>> ---
> >>> V2: No changes
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> index 8476650c477c..52939211fe93 100644
> >>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> >>> @@ -1606,6 +1606,27 @@ static int samsung_dsim_atomic_check(struct
> >>> drm_bridge *bridge,
> >>>adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
> >>> DRM_MODE_FLAG_PVSYNC);
> >>>}
> >>>
> >>> + /*
> >>> + * When using video sync pulses, the HFP, HBP, and HSA are divided
> >>> between
> >>> + * the available lanes if there is more than one lane. For certain
> >>> + * timings and lane configurations, the HFP may not be evenly
> >>> divisible.
> >>> + * If the HFP is rounded down, it ends up being too small which can
> >>> cause
> >>> + * some monitors to not sync properly. In these instances, adjust
> >>> htotal
> >>> + * and hsync to round the HFP up, and recalculate the htotal.
> >>> Through trial
> >>> + * and error, it appears that the HBP and HSA do not appearto need
> >>> the same
> >>> + * correction that HFP does.
> >>> + */
> >>> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes
> >>> > 1) {
> >>
> >> Does this also apply to mode with sync events (I suspect it does), so
> >> the condition here should likely be if (!...burst mode) , right ?
> >
> > Thanks for the review!
> >
> > I was only able to test it with the DSI->ADV6535 bridge, and I'll
> > admit I don't know a lot about DSI interface since I don't have a copy
> > of the spec to read.
> >
> > Are you proposing this should be:
> >
> > if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) && dsi->lanes > 1) {
> >
> > I just want to make sure I understand what you're requesting.
>
> Yes, exactly this.
Do you think it should also include checks for
MIPI_DSI_MODE_VIDEO_NO_HFP, MIPI_DSI_MODE_VIDEO_NO_HBP or
MIPI_DSI_MODE_VIDEO_NO_HSA?
It seems like if any of these are set, we should skip this rounding stuff.
adam
Re: [PATCH V2 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding
On Sun, Apr 21, 2024 at 9:36 AM Marek Vasut wrote:
>
> On 2/12/24 12:09 AM, Adam Ford wrote:
> > When using video sync pulses, the HFP, HBP, and HSA are divided between
> > the available lanes if there is more than one lane. For certain
> > timings and lane configurations, the HFP may not be evenly divisible.
> > If the HFP is rounded down, it ends up being too small which can cause
> > some monitors to not sync properly. In these instances, adjust htotal
> > and hsync to round the HFP up, and recalculate the htotal.
> >
> > Tested-by: Frieder Schrempf # Kontron BL
> > i.MX8MM with HDMI monitor
> > Signed-off-by: Adam Ford
> > ---
> > V2: No changes
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> > b/drivers/gpu/drm/bridge/samsung-dsim.c
> > index 8476650c477c..52939211fe93 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -1606,6 +1606,27 @@ static int samsung_dsim_atomic_check(struct
> > drm_bridge *bridge,
> > adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
> > DRM_MODE_FLAG_PVSYNC);
> > }
> >
> > + /*
> > + * When using video sync pulses, the HFP, HBP, and HSA are divided
> > between
> > + * the available lanes if there is more than one lane. For certain
> > + * timings and lane configurations, the HFP may not be evenly
> > divisible.
> > + * If the HFP is rounded down, it ends up being too small which can
> > cause
> > + * some monitors to not sync properly. In these instances, adjust
> > htotal
> > + * and hsync to round the HFP up, and recalculate the htotal. Through
> > trial
> > + * and error, it appears that the HBP and HSA do not appearto need
> > the same
> > + * correction that HFP does.
> > + */
> > + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes >
> > 1) {
>
> Does this also apply to mode with sync events (I suspect it does), so
> the condition here should likely be if (!...burst mode) , right ?
Thanks for the review!
I was only able to test it with the DSI->ADV6535 bridge, and I'll
admit I don't know a lot about DSI interface since I don't have a copy
of the spec to read.
Are you proposing this should be:
if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) && dsi->lanes > 1) {
I just want to make sure I understand what you're requesting.
thanks
adam
[PATCH V2] drm/bridge: imx: Fix unmet depenency for PHY_FSL_SAMSUNG_HDMI_PHY
When enabling i.MX8MP DWC HDMI driver, it automatically selects
PHY_FSL_SAMSUNG_HDMI_PHY, since it wont' work without the phy.
This may cause some Kconfig warnings during various build tests.
Fix this by implying the phy instead of selecting the phy.
To prevent this from happening with the DRM_IMX8MP_HDMI_PVI, also
imply it instead of selecting it.
Fixes: 1f36d634670d ("drm/bridge: imx: add bridge wrapper driver for i.MX8MP
DWC HDMI")
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404190103.llm8ltup-...@intel.com/
Signed-off-by: Adam Ford
---
V2: Change DRM_IMX8MP_HDMI_PVI at the same time since it was affected
from the same commit.
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index 7687ed652df5..13142a6b8590 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -8,8 +8,8 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
depends on COMMON_CLK
depends on DRM_DW_HDMI
depends on OF
- select DRM_IMX8MP_HDMI_PVI
- select PHY_FSL_SAMSUNG_HDMI_PHY
+ imply DRM_IMX8MP_HDMI_PVI
+ imply PHY_FSL_SAMSUNG_HDMI_PHY
help
Choose this to enable support for the internal HDMI encoder found
on the i.MX8MP SoC.
--
2.43.0
[PATCH] drm/bridge: imx: Fix unmet depenency for PHY_FSL_SAMSUNG_HDMI_PHY
When enabling i.MX8MP DWC HDMI driver, it automatically selects
PHY_FSL_SAMSUNG_HDMI_PHY, since it wont' work without the phy.
This may cause some Kconfig warnings during various build tests.
Fix this by implying the phy instead of selecting the phy.
Fixes: 1f36d634670d ("drm/bridge: imx: add bridge wrapper driver for i.MX8MP
DWC HDMI")
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404190103.llm8ltup-...@intel.com/
Signed-off-by: Adam Ford
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index 7687ed652df5..8f125c75050d 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -9,7 +9,7 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
depends on DRM_DW_HDMI
depends on OF
select DRM_IMX8MP_HDMI_PVI
- select PHY_FSL_SAMSUNG_HDMI_PHY
+ imply PHY_FSL_SAMSUNG_HDMI_PHY
help
Choose this to enable support for the internal HDMI encoder found
on the i.MX8MP SoC.
--
2.43.0
Re: [PATCH V2 2/2] arm64: dts: imx8mp-beacon-kit: Enable HDMI bridge HPD
On Mon, Mar 4, 2024 at 6:49 PM Adam Ford wrote:
>
> The DSI to HDMI bridge supports hot-plut-detect, but the
> driver didn't previously support a shared IRQ GPIO. With
> the driver updated, the interrupt can be added to the bridge.
>
> Signed-off-by: Adam Ford
> Reviewed-by: Laurent Pinchart
Shawn,
Patch 1/2 has been applied and sits in linux-next. Are you OK to
apply this to the IMX branch so the hot-plug detection can work?
Thank you,
adam
adam
> ---
> V2: No Change
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
> b/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
> index a08057410bde..fba8fd04398d 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
> @@ -304,6 +304,8 @@ adv_bridge: hdmi@3d {
> compatible = "adi,adv7535";
> reg = <0x3d>, <0x3c>, <0x3e>, <0x3f>;
> reg-names = "main", "cec", "edid", "packet";
> + interrupt-parent = <>;
> + interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
> adi,dsi-lanes = <4>;
> #sound-dai-cells = <0>;
>
> --
> 2.43.0
>
Re: [PATCH V2 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding
On Sun, Feb 11, 2024 at 5:09 PM Adam Ford wrote:
>
> When using video sync pulses, the HFP, HBP, and HSA are divided between
> the available lanes if there is more than one lane. For certain
> timings and lane configurations, the HFP may not be evenly divisible.
> If the HFP is rounded down, it ends up being too small which can cause
> some monitors to not sync properly. In these instances, adjust htotal
> and hsync to round the HFP up, and recalculate the htotal.
>
Marek V and Marek S,
Would either of you be willing to test that this doesn't break your
applications?
thanks
adam
> Tested-by: Frieder Schrempf # Kontron BL
> i.MX8MM with HDMI monitor
> Signed-off-by: Adam Ford
> ---
> V2: No changes
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 8476650c477c..52939211fe93 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1606,6 +1606,27 @@ static int samsung_dsim_atomic_check(struct drm_bridge
> *bridge,
> adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC);
> }
>
> + /*
> +* When using video sync pulses, the HFP, HBP, and HSA are divided
> between
> +* the available lanes if there is more than one lane. For certain
> +* timings and lane configurations, the HFP may not be evenly
> divisible.
> +* If the HFP is rounded down, it ends up being too small which can
> cause
> +* some monitors to not sync properly. In these instances, adjust
> htotal
> +* and hsync to round the HFP up, and recalculate the htotal. Through
> trial
> +* and error, it appears that the HBP and HSA do not appearto need
> the same
> +* correction that HFP does.
> +*/
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes >
> 1) {
> + int hfp = adjusted_mode->hsync_start -
> adjusted_mode->hdisplay;
> + int remainder = hfp % dsi->lanes;
> +
> + if (remainder) {
> + adjusted_mode->hsync_start += remainder;
> + adjusted_mode->hsync_end += remainder;
> + adjusted_mode->htotal += remainder;
> + }
> + }
> +
> return 0;
> }
>
> --
> 2.43.0
>
Re: [PATCH V2 1/2] drm/bridge: adv7511: Allow IRQ to share GPIO pins
On Tue, Mar 5, 2024 at 2:18 AM Laurent Pinchart wrote: > > Hello Adam, > > Thank you for the patch. > > On Mon, Mar 04, 2024 at 06:48:57PM -0600, Adam Ford wrote: > > The IRQ registration currently assumes that the GPIO is dedicated > > to it, but that may not necessarily be the case. If the board has > > another device sharing the GPIO, it won't be registered and the > > hot-plug detect fails to function. > > > > Currently, the handler reads two registers and blindly > > assumes one of them caused the interrupt and returns IRQ_HANDLED > > unless there is an error. In order to properly do this, the IRQ > > handler needs to check if it needs to handle the IRQ and return > > IRQ_NONE if there is nothing to handle. With the check added > > and the return code properly indicating whether or not it there > > was an IRQ, the IRQF_SHARED can be set to share a GPIO IRQ. > > > > Signed-off-by: Adam Ford > > Reviewed-by: Laurent Pinchart Gentle nudge on this one. It's been about a month, and without it, it is preventing hot-plug detection on one board for me. Thanks adam > > > --- > > V2: Add check to see if there is IRQ data to handle > > > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > > index b5518ff97165..f3b4616a8fb6 100644 > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > > @@ -477,6 +477,11 @@ static int adv7511_irq_process(struct adv7511 > > *adv7511, bool process_hpd) > > if (ret < 0) > > return ret; > > > > + /* If there is no IRQ to handle, exit indicating no IRQ data */ > > + if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) && > > + !(irq1 & ADV7511_INT1_DDC_ERROR)) > > + return -ENODATA; > > + > > regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0); > > regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1); > > > > @@ -1318,7 +1323,8 @@ static int adv7511_probe(struct i2c_client *i2c) > > > > ret = devm_request_threaded_irq(dev, i2c->irq, NULL, > > adv7511_irq_handler, > > - IRQF_ONESHOT, dev_name(dev), > > + IRQF_ONESHOT | IRQF_SHARED, > > + dev_name(dev), > > adv7511); > > if (ret) > > goto err_unregister_audio; > > -- > Regards, > > Laurent Pinchart
Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI
On Tue, Mar 26, 2024 at 2:46 AM Tommaso Merciai wrote: > > Hi Laurent, > > On Tue, Mar 26, 2024 at 12:03:38AM +0200, Laurent Pinchart wrote: > > Hi Tommaso, > > > > On Mon, Mar 25, 2024 at 10:48:56PM +0100, Tommaso Merciai wrote: > > > Hi Adam, Lucas, > > > Thanks for this series. > > > > > > This series make HDMI work on evk. > > > All is working properly on my side. > > > > > > Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1. > > > Hope this help. > > > > > > Tested-by: Tommaso Merciai > > > > The DRM side has been merged already. The only missing patches are for > > the PHY, and the latest version can be found in > > https://lore.kernel.org/linux-phy/20240227220444.77566-1-aford...@gmail.com/. > > You can test that series and send a Tested-by tag. I'm crossing my > > fingers and hoping it will be merged in v6.10. > (same here :) ) > > Thanks for sharing! :) > > To be honest I test all this series rebasing my alvium next branch on top of > media_stage/master (6.9.0-rc1) > All is working properly on my side. > I found v8 into the commit msg here: > https://patches.linaro.org/project/linux-pm/patch/20240203165307.7806-9-aford...@gmail.com/ > then I'm thinking this is the latest. > > I'm going to switch to your suggestion that looks more recent :) Sorry about the confusion. I was confused by the versioning too when I pulled from different parts of Lucas' stuff. Since varying components were applied at different times, and the remaining part was based on the wrong starting point and not applied, I reverted back to the versioning of the PHY which was the only remaining part other than device tree stuff. adam > > Thanks again, > Tommaso > > > > > > On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote: > > > > The i.MX8M Plus has an HDMI controller, but it depends on two > > > > other systems, the Parallel Video Interface (PVI) and the > > > > HDMI PHY from Samsung. The LCDIF controller generates the display > > > > and routes it to the PVI which converts passes the parallel video > > > > to the HDMI bridge. The HDMI system has a corresponding power > > > > domain controller whose driver was partially written, but the > > > > device tree for it was never applied, so some changes to the > > > > power domain should be harmless because they've not really been > > > > used yet. > > > > > > > > This series is adapted from multiple series from Lucas Stach with > > > > edits and suggestions from feedback from various series, but it > > > > since it's difficult to use and test them independently, > > > > I merged them into on unified series. The version history is a > > > > bit ambiguous since different components were submitted at different > > > > times and had different amount of retries. In an effort to merge them > > > > I used the highest version attempt. > > > > > > > > Adam Ford (3): > > > > dt-bindings: soc: imx: add missing clock and power-domains to > > > > imx8mp-hdmi-blk-ctrl > > > > pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix > > > > domain > > > > arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module > > > > > > > > Lucas Stach (9): > > > > dt-bindings: phy: add binding for the i.MX8MP HDMI PHY > > > > phy: freescale: add Samsung HDMI PHY > > > > arm64: dts: imx8mp: add HDMI power-domains > > > > arm64: dts: imx8mp: add HDMI irqsteer > > > > dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI > > > > drm/bridge: imx: add driver for HDMI TX Parallel Video Interface > > > > dt-bindings: display: imx: add binding for i.MX8MP HDMI TX > > > > drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI > > > > arm64: dts: imx8mp: add HDMI display pipeline > > > > > > > > .../display/bridge/fsl,imx8mp-hdmi-tx.yaml| 102 ++ > > > > .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 84 ++ > > > > .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml | 62 + > > > > .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml | 22 +- > > > > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 145 +++ > > > > arch/arm64/configs/defconfig |1 + > > > > drivers/gpu/drm/bridge/imx/Kconfig| 18 + > > > > drivers/gpu/drm/bridge/imx/Makefile |2 + > > > >
Re: [PATCH 1/6] dt-bindings: gpu: powervr-rogue: Add PowerVR support for some Renesas GPUs
On Thu, Mar 7, 2024 at 6:41 AM Frank Binns wrote: > > Hi Adam, > > On Mon, 2024-02-26 at 21:45 -0600, Adam Ford wrote: > > Update the binding to add support for various Renesas SoC's with PowerVR > > Rogue GX6250 and GX6650 GPUs. These devices only need one clock, so update > > the table to indicate such like what was done for the ti,am62-gpu. > > > > Signed-off-by: Adam Ford > > > > diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > > b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > > index 256e252f8087..7c75104df09f 100644 > > --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > > +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > > @@ -14,6 +14,11 @@ properties: > >compatible: > > items: > >- enum: > > + - renesas,r8a774a1-gpu > > + - renesas,r8a774e1-gpu > > + - renesas,r8a77951-gpu > > + - renesas,r8a77960-gpu > > + - renesas,r8a77961-gpu > >- ti,am62-gpu > >- const: img,img-axe # IMG AXE GPU model/revision is fully > > discoverable > > A new set of items should be added for 'img,powervr-series6xt' and the Renesas > models along the lines of [1]. Should I rebase my binding off the one below, so it applies to your branch or should I attempt to base it off the mainline? > > Thanks > Frank > > [1] > https://gitlab.freedesktop.org/imagination/linux/-/blob/powervr-next/Documentation/devicetree/bindings/gpu/img,powervr.yaml?ref_type=heads#L16-19 > > > > > @@ -51,7 +56,13 @@ allOf: > >properties: > > compatible: > >contains: > > -const: ti,am62-gpu > > +enum: > > + - ti,am62-gpu > > + - renesas,r8a774a1-gpu > > + - renesas,r8a774e1-gpu > > + - renesas,r8a77951-gpu > > + - renesas,r8a77960-gpu > > + - renesas,r8a77961-gpu > > then: > >properties: > > clocks:
Re: [PATCH 2/6] arm64: dts: renesas: r8a774a1: Enable GPU
On Thu, Mar 7, 2024 at 6:37 AM Frank Binns wrote:
>
> On Thu, 2024-03-07 at 12:26 +, Frank Binns wrote:
> > On Tue, 2024-02-27 at 05:50 -0600, Adam Ford wrote:
> > > On Tue, Feb 27, 2024 at 3:31 AM Matt Coster
> > > wrote:
> > > > Hi Adam,
> > > >
> > > > Thanks for these patches! I'll just reply to this one patch, but my
> > > > comments apply to them all.
> > > >
> > > > On 27/02/2024 03:45, Adam Ford wrote:
> > > > > The GPU on the RZ/G2M is a Rogue GX6250 which uses firmware
> > > > > rogue_4.45.2.58_v1.fw available from Imagination.
> > > > >
> > > > > When enumerated, it appears as:
> > > > > powervr fd00.gpu: [drm] loaded firmware
> > > > > powervr/rogue_4.45.2.58_v1.fw
> > > > > powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
> > > >
> > > > These messages are printed after verifying the firmware blob’s headers,
> > > > *before* attempting to upload it to the device. Just because they appear
> > > > in dmesg does *not* imply the device is functional beyond the handful of
> > > > register reads in pvr_load_gpu_id().
> > > >
> > > > Since Mesa does not yet have support for this GPU, there’s not a lot
> > > > that can be done to actually test these bindings.
> > > >
> > > > When we added upstream support for the first GPU (the AXE core in TI’s
> > > > AM62), we opted to wait until userspace was sufficiently progressed to
> > > > the point it could be used for testing. This thought process still
> > > > applies when adding new GPUs.
> > > >
> > > > Our main concern is that adding bindings for GPUs implies a level of
> > > > support that cannot be tested. That in turn may make it challenging to
> > > > justify UAPI changes if/when they’re needed to actually make these GPUs
> > > > functional.
> > >
> > > I wrongly assumed that when the firmware was ready, there was some
> > > preliminary functionality, but it sounds like we need to work for
> > > Series6XT support to be added to the driver. I only used the AXE
> > > compatible since it appeared to the be the only one and the existing
> > > binding document stated "model/revision is fully discoverable" which I
> > > interpreted to mean that the AXE compatible was sufficient.
> >
> > The comment is related to there being a few models/revisions of AXE
> > [1][2][3],
> > which we can distinguish between by reading a register.
> >
> > > > > Signed-off-by: Adam Ford
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > > > b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > > > index a8a44fe5e83b..8923d9624b39 100644
> > > > > --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > > > +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > > > @@ -2352,6 +2352,16 @@ gic: interrupt-controller@f101 {
> > > > > resets = < 408>;
> > > > > };
> > > > >
> > > > > + gpu: gpu@fd00 {
> > > > > + compatible = "renesas,r8a774a1-gpu",
> > > > > "img,img-axe";
> > > >
> > > > The GX6250 is *not* an AXE core - it shouldn’t be listed as compatible
> > > > with one. For prior art, see [1] where we added support for the MT8173
> > > > found in Elm Chromebooks R13 (also a Series6XT GPU).
> > > >
> > > > > + reg = <0 0xfd00 0 0x2>;
> > > > > + clocks = < CPG_MOD 112>;
> > > > > + clock-names = "core";
> > > >
> > > > Series6XT cores have three clocks (see [1] again). I don’t have a
> > > > Renesas TRM to hand – do you know if their docs go into detail on the
> > > > GPU integration?
> > > >
> > > > > + interrupts = ;
> > > > > + power-domains = < R8A774A1_PD_3DG_B>;
> > > > > + resets = < 112>;
> > > > > + };
> > > > > +
> > > > > pciec0: pcie@fe00 {
> > > > > compatible = "renesas,pcie-r8a774a1",
> >
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Tue, Mar 5, 2024 at 5:58 AM Frank Binns wrote:
>
> Hi Adam,
>
> Sorry for not responding sooner. I've recently just returned from paternity
> leave, so just catching up on everything.
Congratulations!
>
> On Thu, 2024-02-15 at 11:22 -0600, Adam Ford wrote:
> > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford wrote:
> > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > > wrote:
> > > > Hi Maxime,
> > > >
> > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
> > > > wrote:
> > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > > > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > > > > proprietary firmware image, which is currently only available for
> > > > > > Texas
> > > > > > Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to
> > > > > > prevent asking the user about this driver when configuring a kernel
> > > > > > without Texas Instruments K3 Multicore SoC support.
> > > > >
> > > > > This wasn't making sense the first time you sent it, and now that
> > > > > commit
> > > > > log is just plain wrong. We have firmwares for the G6110, GX6250,
> > > > > GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at
> > > > > least)
> > > > > Renesas, Mediatek, Rockchip, TI and StarFive, so across three
> > > >
> > > > I am so happy to be proven wrong!
> > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
> > > >
> > > > > architectures and 5 platforms. In two months.
> > > >
> > > > That sounds like great progress, thanks a lot!
> > > >
> > > Geert,
> > >
> > > > Where can I find these firmwares? Linux-firmware[1] seems to lack all
> > > > but the original K3 AM62x one.
> > >
> > > I think PowerVR has a repo [1], but the last time I checked it, the
> > > BVNC for the firmware didn't match what was necessary for the GX6250
> > > on the RZ/G2M. I can't remember what the corresponding R-Car3 model
> > > is. I haven't tried recently because I was told more documentation
> > > for firmware porting would be delayed until everything was pushed into
> > > the kernel and Mesa. Maybe there is a better repo and/or newer
> > > firmware somewhere else.
> > >
> > I should have doubled checked the repo contents before I sent my last
> > e-mail , but it appears the firmware [2] for the RZ/G2M, might be
> > present now. I don't know if there are driver updates necessary. I
> > checked my e-mails, but I didn't see any notification, or I would have
> > tried it earlier. Either way, thank you Frank for adding it. I'll
> > try to test when I have some time.
> >
>
> You may have noticed from one of Matt's emails that we now have a set of repos
> (linux, linux-firmware and Mesa) in our own area on freedesktop.org GitLab:
> https://gitlab.freedesktop.org/imagination/
>
> We'll be using this as a staging area for work that isn't ready to be
> upstreamed
> yet (including firmware binaries).
>
I tried to play with these a little, but it seems like there is still
a fair amount of work to be done on the 6XT series. I tried to add the
device tree support for several Renesas boards, but the series was
NAK'd due to an inability to test it.
>
> > > adam
> > >
> > > [1]
> > > https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr/powervr?ref_type=heads
> >
> > [2] -
> > https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b
> >
>
> This is now the place to get the firmware for devices that aren't yet
> supported
> upstream:
> https://gitlab.freedesktop.org/imagination/linux-firmware/-/commits/powervr/?ref_type=HEADS
>
I've been following several of these repos and checking for software
updates in both the Firmware, driver and userspace layers.
> With the firmware for the Renesas variant of GX6250 being found in this
> commit:
> https://gitlab.freedesktop.org/imagination/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b
>
If your group thinks they have stuff they want tested, I am willing to
test them on the two platforms I have if I am CC'd on anything.
Thanks for the work your group has done so far. It'll be nice to see the work.
adam
> Thanks
> Frank
>
> > >
> > > > Thanks again!
> > > >
> > > > [1]
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> > > >
> > > > Gr{oetje,eeting}s,
> > > >
> > > > Geert
> > > >
> > > > --
> > > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> > > > ge...@linux-m68k.org
> > > >
> > > > In personal conversations with technical people, I call myself a
> > > > hacker. But
> > > > when I'm talking to journalists I just say "programmer" or something
> > > > like that.
> > > > -- Linus Torvalds
[PATCH V2 2/2] arm64: dts: imx8mp-beacon-kit: Enable HDMI bridge HPD
The DSI to HDMI bridge supports hot-plut-detect, but the
driver didn't previously support a shared IRQ GPIO. With
the driver updated, the interrupt can be added to the bridge.
Signed-off-by: Adam Ford
Reviewed-by: Laurent Pinchart
---
V2: No Change
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
b/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
index a08057410bde..fba8fd04398d 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
@@ -304,6 +304,8 @@ adv_bridge: hdmi@3d {
compatible = "adi,adv7535";
reg = <0x3d>, <0x3c>, <0x3e>, <0x3f>;
reg-names = "main", "cec", "edid", "packet";
+ interrupt-parent = <>;
+ interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
adi,dsi-lanes = <4>;
#sound-dai-cells = <0>;
--
2.43.0
[PATCH V2 1/2] drm/bridge: adv7511: Allow IRQ to share GPIO pins
The IRQ registration currently assumes that the GPIO is dedicated to it, but that may not necessarily be the case. If the board has another device sharing the GPIO, it won't be registered and the hot-plug detect fails to function. Currently, the handler reads two registers and blindly assumes one of them caused the interrupt and returns IRQ_HANDLED unless there is an error. In order to properly do this, the IRQ handler needs to check if it needs to handle the IRQ and return IRQ_NONE if there is nothing to handle. With the check added and the return code properly indicating whether or not it there was an IRQ, the IRQF_SHARED can be set to share a GPIO IRQ. Signed-off-by: Adam Ford --- V2: Add check to see if there is IRQ data to handle diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index b5518ff97165..f3b4616a8fb6 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -477,6 +477,11 @@ static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd) if (ret < 0) return ret; + /* If there is no IRQ to handle, exit indicating no IRQ data */ + if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) && + !(irq1 & ADV7511_INT1_DDC_ERROR)) + return -ENODATA; + regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0); regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1); @@ -1318,7 +1323,8 @@ static int adv7511_probe(struct i2c_client *i2c) ret = devm_request_threaded_irq(dev, i2c->irq, NULL, adv7511_irq_handler, - IRQF_ONESHOT, dev_name(dev), + IRQF_ONESHOT | IRQF_SHARED, + dev_name(dev), adv7511); if (ret) goto err_unregister_audio; -- 2.43.0
Re: [PATCH 1/2] drm/bridge: adv7511: Allow IRQ to share GPIO pins
On Wed, Feb 28, 2024 at 10:31 AM Laurent Pinchart
wrote:
>
> Hi Adam,
>
> Thank you for the patch.
>
> On Wed, Feb 28, 2024 at 05:37:35AM -0600, Adam Ford wrote:
> > The IRQ registration currently assumes that the GPIO is
> > dedicated to it, but that may not necessarily be the case.
> > If the board has another device sharing the IRQ, it won't be
> > registered and the hot-plug detect fails. This is easily
> > fixed by add the IRQF_SHARED flag.
> >
> > Signed-off-by: Adam Ford
> >
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > index b5518ff97165..21f08b2ae265 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > @@ -1318,7 +1318,8 @@ static int adv7511_probe(struct i2c_client *i2c)
> >
> > ret = devm_request_threaded_irq(dev, i2c->irq, NULL,
> > adv7511_irq_handler,
> > - IRQF_ONESHOT, dev_name(dev),
> > + IRQF_ONESHOT | IRQF_SHARED,
> > + dev_name(dev),
>
> This looks fine, but the IRQ handler doesn't.
Thanks for the review.
>
> static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd)
> {
> unsigned int irq0, irq1;
> int ret;
>
> ret = regmap_read(adv7511->regmap, ADV7511_REG_INT(0), );
> if (ret < 0)
> return ret;
>
> ret = regmap_read(adv7511->regmap, ADV7511_REG_INT(1), );
> if (ret < 0)
> return ret;
If I did a check here and returned if there was no IRQ to handle,
would that be sufficient?
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -477,6 +477,11 @@ static int adv7511_irq_process(struct adv7511
*adv7511, bool process_hpd)
if (ret < 0)
return ret;
+ /* If there is no IRQ to handle, exit indicating no IRQ handled */
+ if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) &&
+ !(irq1 & ADV7511_INT1_DDC_ERROR))
+ return -1;
+
regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0);
regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
With this, I would expect adv7511_irq_handler to return IRQ_NONE. If
you're OK with that approach, I can do that. If you want me to merge
adv7511_irq_handler, and adv7511_irq_process, I can do that too to
make the return codes a little more intuitive.
adam
>
> regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0);
> regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
>
> if (process_hpd && irq0 & ADV7511_INT0_HPD && adv7511->bridge.encoder)
> schedule_work(>hpd_work);
>
> if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
> adv7511->edid_read = true;
>
> if (adv7511->i2c_main->irq)
> wake_up_all(>wq);
> }
>
> #ifdef CONFIG_DRM_I2C_ADV7511_CEC
> adv7511_cec_irq_process(adv7511, irq1);
> #endif
>
> return 0;
> }
>
> static irqreturn_t adv7511_irq_handler(int irq, void *devid)
> {
> struct adv7511 *adv7511 = devid;
> int ret;
>
> ret = adv7511_irq_process(adv7511, true);
> return ret < 0 ? IRQ_NONE : IRQ_HANDLED;
> }
>
> The function will return IRQ_HANDLED as long as the registers can be
> read, even if they don't report any interrupt.
>
> > adv7511);
> > if (ret)
> > goto err_unregister_audio;
>
> --
> Regards,
>
> Laurent Pinchart
[PATCH 2/2] arm64: dts: imx8mp-beacon-kit: Enable HDMI bridge HPD
The DSI to HDMI bridge supports hot-plut-detect, but the
driver didn't previously support a shared IRQ GPIO. With
the driver updated, the interrupt can be added to the bridge.
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
b/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
index 8de4dd268908..d854c94ec997 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
@@ -405,6 +405,8 @@ adv_bridge: hdmi@3d {
compatible = "adi,adv7535";
reg = <0x3d>, <0x3c>, <0x3e>, <0x3f>;
reg-names = "main", "cec", "edid", "packet";
+ interrupt-parent = <>;
+ interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
adi,dsi-lanes = <4>;
#sound-dai-cells = <0>;
--
2.43.0
[PATCH 1/2] drm/bridge: adv7511: Allow IRQ to share GPIO pins
The IRQ registration currently assumes that the GPIO is dedicated to it, but that may not necessarily be the case. If the board has another device sharing the IRQ, it won't be registered and the hot-plug detect fails. This is easily fixed by add the IRQF_SHARED flag. Signed-off-by: Adam Ford diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index b5518ff97165..21f08b2ae265 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -1318,7 +1318,8 @@ static int adv7511_probe(struct i2c_client *i2c) ret = devm_request_threaded_irq(dev, i2c->irq, NULL, adv7511_irq_handler, - IRQF_ONESHOT, dev_name(dev), + IRQF_ONESHOT | IRQF_SHARED, + dev_name(dev), adv7511); if (ret) goto err_unregister_audio; -- 2.43.0
Re: [PATCH V2 1/2] drm/bridge: samsung-dsim: Set P divider based on min/max of fin pll
On Sun, Feb 11, 2024 at 5:09 PM Adam Ford wrote:
>
> The P divider should be set based on the min and max values of
> the fin pll which may vary between different platforms.
> These ranges are defined per platform, but hard-coded values
> were used instead which resulted in a smaller range available
> on the i.MX8M[MNP] than what was possible.
>
> As noted by Frieder, there are descripencies between the reference
> manuals of the Mini, Nano and Plus, so I reached out to my NXP
> rep and got the following response regarding the varing notes
> in the documentation.
>
> "Yes it is definitely wrong, the one that is part of the NOTE in
> MIPI_DPHY_M_PLLPMS register table against PMS_P, PMS_M and PMS_S is
> not correct. I will report this to Doc team, the one customer should
> be take into account is the Table 13-40 DPHY PLL Parameters and the
> Note above."
>
> With this patch, the clock rates now match the values used in NXP's
> downstream kernel.
>
Inki,
Any change either or both of these patches could get applied? It's
been several months since the first submission.
Fabio - Do you have an 8MP-evk that you could test to see if there is
any impact? Between these two patches, it fixes the 720p@60 and
likely others too.
adam
> Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock")
> Signed-off-by: Adam Ford
> Reviewed-by: Frieder Schrempf
> Tested-by: Frieder Schrempf
> ---
> V2: Only update the commit message to reflect why these values
> were chosen. No code change present
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 95fedc68b0ae..8476650c477c 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -574,8 +574,8 @@ static unsigned long samsung_dsim_pll_find_pms(struct
> samsung_dsim *dsi,
> u16 _m, best_m;
> u8 _s, best_s;
>
> - p_min = DIV_ROUND_UP(fin, (12 * MHZ));
> - p_max = fin / (6 * MHZ);
> + p_min = DIV_ROUND_UP(fin, (driver_data->pll_fin_max * MHZ));
> + p_max = fin / (driver_data->pll_fin_min * MHZ);
>
> for (_p = p_min; _p <= p_max; ++_p) {
> for (_s = 0; _s <= 5; ++_s) {
> --
> 2.43.0
>
Re: [PATCH 4/6] arm64: dts: renesas: r8a77951: Enable GPU
On Tue, Feb 27, 2024 at 2:11 AM Geert Uytterhoeven wrote:
>
> Hi Adam,
>
> Thanks for your patch!
>
> On Tue, Feb 27, 2024 at 4:46 AM Adam Ford wrote:
> > The GPU on the R-Car H3 is a Rogue GX6650 which uses firmware
> > rogue_4.46.6.61_v1.fw available from Imagination.
>
> s/61/62/
>
> >
> > When enumerated, it appears as:
> > powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.46.6.62_v1.fw
> > powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
>
> Do you have a different build number?
I don't actually have this board. I just copy-pasted what I thought
it was. If you have build number that's more appropriate, I can use
that in the future.
adam
>
> On Salvator-XS with R-Car H3 ES2.0:
>
> powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.46.6.62_v1.fw
> powervr fd00.gpu: [drm] FW version v1.0 (build 6538781 OS)
> [drm] Initialized powervr 1.0.0 20230904 for fd00.gpu on minor 1
>
> >
> > Signed-off-by: Adam Ford
>
> Tested-by: Geert Uytterhoeven
>
> > --- a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
> > @@ -2771,6 +2771,16 @@ gic: interrupt-controller@f101 {
> > resets = < 408>;
> > };
> >
> > + gpu: gpu@fd00 {
> > + compatible = "renesas,r8a77951-gpu", "img,img-axe";
>
> renesas,r8a7795-gpu
>
> > + reg = <0 0xfd00 0 0x2>;
> > + clocks = < CPG_MOD 112>;
> > + clock-names = "core";
> > + interrupts = ;
> > + power-domains = < R8A7795_PD_3DG_E>;
> > + resets = < 112>;
> > + };
> > +
> > pciec0: pcie@fe00 {
> > compatible = "renesas,pcie-r8a7795",
> > "renesas,pcie-rcar-gen3";
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH 2/6] arm64: dts: renesas: r8a774a1: Enable GPU
On Tue, Feb 27, 2024 at 5:04 AM Geert Uytterhoeven wrote:
>
> Hi Matt,
>
> On Tue, Feb 27, 2024 at 10:31 AM Matt Coster wrote:
> >
> > Hi Adam,
> >
> > Thanks for these patches! I'll just reply to this one patch, but my
> > comments apply to them all.
> >
> > On 27/02/2024 03:45, Adam Ford wrote:
> > > The GPU on the RZ/G2M is a Rogue GX6250 which uses firmware
> > > rogue_4.45.2.58_v1.fw available from Imagination.
> > >
> > > When enumerated, it appears as:
> > > powervr fd00.gpu: [drm] loaded firmware
> > > powervr/rogue_4.45.2.58_v1.fw
> > > powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
> >
> > These messages are printed after verifying the firmware blob’s headers,
> > *before* attempting to upload it to the device. Just because they appear
> > in dmesg does *not* imply the device is functional beyond the handful of
> > register reads in pvr_load_gpu_id().
> >
> > Since Mesa does not yet have support for this GPU, there’s not a lot
> > that can be done to actually test these bindings.
>
> OK.
>
> > When we added upstream support for the first GPU (the AXE core in TI’s
> > AM62), we opted to wait until userspace was sufficiently progressed to
> > the point it could be used for testing. This thought process still
> > applies when adding new GPUs.
> >
> > Our main concern is that adding bindings for GPUs implies a level of
> > support that cannot be tested. That in turn may make it challenging to
> > justify UAPI changes if/when they’re needed to actually make these GPUs
> > functional.
>
> I guess that applies to "[PATCH 00/11] Device tree support for
> Imagination Series5 GPU", too, which has been in linux-next for about
> a month?
> https://lore.kernel.org/all/20240109171950.31010-1-...@ti.com/
>
> > > Signed-off-by: Adam Ford
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > index a8a44fe5e83b..8923d9624b39 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > > @@ -2352,6 +2352,16 @@ gic: interrupt-controller@f101 {
> > > resets = < 408>;
> > > };
> > >
> > > + gpu: gpu@fd00 {
> > > + compatible = "renesas,r8a774a1-gpu", "img,img-axe";
> >
> > The GX6250 is *not* an AXE core - it shouldn’t be listed as compatible
> > with one. For prior art, see [1] where we added support for the MT8173
> > found in Elm Chromebooks R13 (also a Series6XT GPU).
>
> IC. And the bindings in [2].
>
> >
> > > + reg = <0 0xfd00 0 0x2>;
> > > + clocks = < CPG_MOD 112>;
> > > + clock-names = "core";
> >
> > Series6XT cores have three clocks (see [1] again). I don’t have a
> > Renesas TRM to hand – do you know if their docs go into detail on the
> > GPU integration?
>
> Not really. The diagram in the Hardware User's Manual just shows the
> following clock inputs:
> - Clock (ZGϕ) from CPG,
> - Clock (S3D1ϕ) from CPG,
> - MSTP (ST112) from CPG.
>
> ZG is the main (programmable) 3DGE clock, running at up to 600 MHz.
> S3D1 is the fixed 266 MHz AXI bus clock.
> MSTP112 is the gateable module clock (part of the SYSC/CPG clock
> domain), and its parent is ZG.
>
> According to the sources:
> - "core" is the primary clock used by the entire GPU core, so we use
> MSTP112 for that.
> - "sys" is the optional system bus clock, so that could be S3D1,
> - "mem" is the optional memory clock, no idea what that would map to.
>
> But IMHO the two optional clocks do not matter at all (the driver
> doesn't care about their rates, and just enables them together with
> the core clock), and S3D1 is always-on, so I'd just limit clocks to
> a single item.
Matt,
When the time is right, and the driver is ready for Series 6XT-based
systems, would Geert's rationale for supporting one clock be
acceptable if I added his clock description to the commit message?
>
> Just wondering: is the availability of 1 clock specific to AXE, or to
> the AXE integration on AM62x?
>
> > + interrupts = ;
> > + power-domains = < R8A774A1_PD_3DG_B>;
> > + resets = < 112>;
> > + };
>
> > [1]:
> > https://gitlab.freedesktop.org/imagination/linux/-/blob/b3506b8bc45ed6d4005eb32a994df0e33d6613f1/arch/arm64/boot/dts/mediatek/mt8173.dtsi#L993-1006
>
> [2]
> https://gitlab.freedesktop.org/imagination/linux/-/blob/b3506b8bc45ed6d4005eb32a994df0e33d6613f1/Documentation/devicetree/bindings/gpu/img,powervr.yaml
>
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH 2/6] arm64: dts: renesas: r8a774a1: Enable GPU
On Tue, Feb 27, 2024 at 3:31 AM Matt Coster wrote:
>
> Hi Adam,
>
> Thanks for these patches! I'll just reply to this one patch, but my
> comments apply to them all.
>
> On 27/02/2024 03:45, Adam Ford wrote:
> > The GPU on the RZ/G2M is a Rogue GX6250 which uses firmware
> > rogue_4.45.2.58_v1.fw available from Imagination.
> >
> > When enumerated, it appears as:
> > powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
> > powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
>
> These messages are printed after verifying the firmware blob’s headers,
> *before* attempting to upload it to the device. Just because they appear
> in dmesg does *not* imply the device is functional beyond the handful of
> register reads in pvr_load_gpu_id().
>
> Since Mesa does not yet have support for this GPU, there’s not a lot
> that can be done to actually test these bindings.
>
> When we added upstream support for the first GPU (the AXE core in TI’s
> AM62), we opted to wait until userspace was sufficiently progressed to
> the point it could be used for testing. This thought process still
> applies when adding new GPUs.
>
> Our main concern is that adding bindings for GPUs implies a level of
> support that cannot be tested. That in turn may make it challenging to
> justify UAPI changes if/when they’re needed to actually make these GPUs
> functional.
I wrongly assumed that when the firmware was ready, there was some
preliminary functionality, but it sounds like we need to work for
Series6XT support to be added to the driver. I only used the AXE
compatible since it appeared to the be the only one and the existing
binding document stated "model/revision is fully discoverable" which I
interpreted to mean that the AXE compatible was sufficient.
>
> > Signed-off-by: Adam Ford
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > index a8a44fe5e83b..8923d9624b39 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > @@ -2352,6 +2352,16 @@ gic: interrupt-controller@f101 {
> > resets = < 408>;
> > };
> >
> > + gpu: gpu@fd00 {
> > + compatible = "renesas,r8a774a1-gpu", "img,img-axe";
>
> The GX6250 is *not* an AXE core - it shouldn’t be listed as compatible
> with one. For prior art, see [1] where we added support for the MT8173
> found in Elm Chromebooks R13 (also a Series6XT GPU).
>
> > + reg = <0 0xfd00 0 0x2>;
> > + clocks = < CPG_MOD 112>;
> > + clock-names = "core";
>
> Series6XT cores have three clocks (see [1] again). I don’t have a
> Renesas TRM to hand – do you know if their docs go into detail on the
> GPU integration?
>
> > + interrupts = ;
> > + power-domains = < R8A774A1_PD_3DG_B>;
> > + resets = < 112>;
> > + };
> > +
> > pciec0: pcie@fe00 {
> > compatible = "renesas,pcie-r8a774a1",
> >"renesas,pcie-rcar-gen3";
>
> As you probably expect by this point, I have to nack this series for
> now. I appreciate your effort here and I’ll be happy to help you land
I get that. I wasn't sure if I should have even pushed this, but I
wanted to get a little traction, because I know there are people like
myself who want to use the 3D in the Renesas boards, but don't want to
use the closed-source blobs tied to EULA and NDA documents.
> these once Mesa gains some form of usable support to allow testing.
Is there a way for your group to add me to the CC list when future
updates are submitted? I'd like to follow this and resubmit when it's
ready.
>
> Cheers,
> Matt
>
> [1]:
> https://gitlab.freedesktop.org/imagination/linux/-/blob/b3506b8bc45ed6d4005eb32a994df0e33d6613f1/arch/arm64/boot/dts/mediatek/mt8173.dtsi#L993-1006
[PATCH 4/6] arm64: dts: renesas: r8a77951: Enable GPU
The GPU on the R-Car H3 is a Rogue GX6650 which uses firmware
rogue_4.46.6.61_v1.fw available from Imagination.
When enumerated, it appears as:
powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.46.6.62_v1.fw
powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
index bea4edd17d53..3e9defaeb00f 100644
--- a/arch/arm64/boot/dts/renesas/r8a77951.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77951.dtsi
@@ -2771,6 +2771,16 @@ gic: interrupt-controller@f101 {
resets = < 408>;
};
+ gpu: gpu@fd00 {
+ compatible = "renesas,r8a77951-gpu", "img,img-axe";
+ reg = <0 0xfd00 0 0x2>;
+ clocks = < CPG_MOD 112>;
+ clock-names = "core";
+ interrupts = ;
+ power-domains = < R8A7795_PD_3DG_E>;
+ resets = < 112>;
+ };
+
pciec0: pcie@fe00 {
compatible = "renesas,pcie-r8a7795",
"renesas,pcie-rcar-gen3";
--
2.43.0
[PATCH 5/6] arm64: dts: renesas: r8a77960: Enable GPU
The GPU on the R-Car M3-W is a Rogue GX6250 which uses firmware
rogue_4.45.2.58_v1.fw available from Imagination.
When enumerated, it appears as:
powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/renesas/r8a77960.dtsi
b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
index 7846fea8e40d..0f17bc3f2d9a 100644
--- a/arch/arm64/boot/dts/renesas/r8a77960.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
@@ -2558,6 +2558,16 @@ gic: interrupt-controller@f101 {
resets = < 408>;
};
+ gpu: gpu@fd00 {
+ compatible = "renesas,r8a77960-gpu", "img,img-axe";
+ reg = <0 0xfd00 0 0x2>;
+ clocks = < CPG_MOD 112>;
+ clock-names = "core";
+ interrupts = ;
+ power-domains = < R8A7796_PD_3DG_B>;
+ resets = < 112>;
+ };
+
pciec0: pcie@fe00 {
compatible = "renesas,pcie-r8a7796",
"renesas,pcie-rcar-gen3";
--
2.43.0
[PATCH 6/6] arm64: dts: renesas: r8a77961: Enable GPU
The GPU on the R-Car M3-W+ is a Rogue GX6250 which uses firmware
rogue_4.45.2.58_v1.fw available from Imagination.
When enumerated, it appears as:
powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
index 58f9286a5ab5..cc17e624c069 100644
--- a/arch/arm64/boot/dts/renesas/r8a77961.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77961.dtsi
@@ -2438,6 +2438,16 @@ gic: interrupt-controller@f101 {
resets = < 408>;
};
+ gpu: gpu@fd00 {
+ compatible = "renesas,r8a77961-gpu", "img,img-axe";
+ reg = <0 0xfd00 0 0x2>;
+ clocks = < CPG_MOD 112>;
+ clock-names = "core";
+ interrupts = ;
+ power-domains = < R8A77961_PD_3DG_B>;
+ resets = < 112>;
+ };
+
pciec0: pcie@fe00 {
compatible = "renesas,pcie-r8a77961",
"renesas,pcie-rcar-gen3";
--
2.43.0
[PATCH 3/6] arm64: dts: renesas: r8a774e1: Enable GPU
The GPU on the RZ/G2H is a Rogue GX6650 which uses firmware
rogue_4.46.6.62_v1.fw available from Imagination.
When enumerated, it appears as:
powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.46.6.62_v1.fw
powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
index be55ae83944c..398c9df1577b 100644
--- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
@@ -2464,6 +2464,16 @@ gic: interrupt-controller@f101 {
resets = < 408>;
};
+ gpu: gpu@fd00 {
+ compatible = "renesas,r8a774e1-gpu", "img,img-axe";
+ reg = <0 0xfd00 0 0x2>;
+ clocks = < CPG_MOD 112>;
+ clock-names = "core";
+ interrupts = ;
+ power-domains = < R8A774E1_PD_3DG_E>;
+ resets = < 112>;
+ };
+
pciec0: pcie@fe00 {
compatible = "renesas,pcie-r8a774e1",
"renesas,pcie-rcar-gen3";
--
2.43.0
[PATCH 1/6] dt-bindings: gpu: powervr-rogue: Add PowerVR support for some Renesas GPUs
Update the binding to add support for various Renesas SoC's with PowerVR Rogue GX6250 and GX6650 GPUs. These devices only need one clock, so update the table to indicate such like what was done for the ti,am62-gpu. Signed-off-by: Adam Ford diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml index 256e252f8087..7c75104df09f 100644 --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml @@ -14,6 +14,11 @@ properties: compatible: items: - enum: + - renesas,r8a774a1-gpu + - renesas,r8a774e1-gpu + - renesas,r8a77951-gpu + - renesas,r8a77960-gpu + - renesas,r8a77961-gpu - ti,am62-gpu - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable @@ -51,7 +56,13 @@ allOf: properties: compatible: contains: -const: ti,am62-gpu +enum: + - ti,am62-gpu + - renesas,r8a774a1-gpu + - renesas,r8a774e1-gpu + - renesas,r8a77951-gpu + - renesas,r8a77960-gpu + - renesas,r8a77961-gpu then: properties: clocks: -- 2.43.0
[PATCH 0/6] gpu: powervr-rogue: Add PowerVR support for some Renesas devices
Renesas has used a few variants of the Power VR GPU in their R-Car and RZ/G2 families. While there is still some work to do at the Mesa level, adding these device tree nodes allows the Power VR driver to enumerate and load the respective firmware located: https://gitlab.freedesktop.org/imagination/linux-firmware/-/tree/powervr/powervr?ref_type=heads Adam Ford (6): dt-bindings: gpu: powervr-rogue: Add PowerVR support for some Renesas GPUs arm64: dts: renesas: r8a774a1: Enable GPU arm64: dts: renesas: r8a774e1: Enable GPU arm64: dts: renesas: r8a77951: Enable GPU arm64: dts: renesas: r8a77960: Enable GPU arm64: dts: renesas: r8a77961: Enable GPU .../devicetree/bindings/gpu/img,powervr-rogue.yaml | 13 - arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 10 ++ arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 10 ++ arch/arm64/boot/dts/renesas/r8a77951.dtsi | 10 ++ arch/arm64/boot/dts/renesas/r8a77960.dtsi | 10 ++ arch/arm64/boot/dts/renesas/r8a77961.dtsi | 10 ++ 6 files changed, 62 insertions(+), 1 deletion(-) -- 2.43.0
[PATCH 2/6] arm64: dts: renesas: r8a774a1: Enable GPU
The GPU on the RZ/G2M is a Rogue GX6250 which uses firmware
rogue_4.45.2.58_v1.fw available from Imagination.
When enumerated, it appears as:
powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index a8a44fe5e83b..8923d9624b39 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -2352,6 +2352,16 @@ gic: interrupt-controller@f101 {
resets = < 408>;
};
+ gpu: gpu@fd00 {
+ compatible = "renesas,r8a774a1-gpu", "img,img-axe";
+ reg = <0 0xfd00 0 0x2>;
+ clocks = < CPG_MOD 112>;
+ clock-names = "core";
+ interrupts = ;
+ power-domains = < R8A774A1_PD_3DG_B>;
+ resets = < 112>;
+ };
+
pciec0: pcie@fe00 {
compatible = "renesas,pcie-r8a774a1",
"renesas,pcie-rcar-gen3";
--
2.43.0
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Tue, Feb 20, 2024 at 5:55 AM Erico Nunes wrote:
>
> Hi,
>
> On Mon, Feb 19, 2024 at 9:38 PM Adam Ford wrote:
> > /usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json
> > ERROR:loader_validate_instance_extensions: Instance
> > extension VK_KHR_wayland_surface not supported by available ICDs or
> > enabled layers.
> > Failed to create Vulkan instance.
> >
> > I have tried running in X.org mode instead of Wayland, but I get a
> > different set of errors:
> >
> > [ 11102.013] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
> > [ 11102.014] (II) Module fbdevhw: vendor="X.Org Foundation"
> > [ 11102.014]compiled for 1.21.1.7, module version = 0.0.2
> > [ 11102.014]ABI class: X.Org Video Driver, version 25.2
> > [ 11102.015] (II) FBDEV(0): using default device
> > [ 11102.016] (II) modeset(G0): using drv /dev/dri/card1
> > [ 11102.016] (EE)
> > Fatal server error:
> > or all framebuffer devices
> > [ 11102.016] (EE)
> > [ 11102.017] (EE)
> > Please consult the The X.Org Foundation support at http://wiki.x.org for
> > help.
>
>
> The wayland and xcb extensions are not really supported at the moment
> in Mesa for powervr, so this kind of use case does not really work
> yet. For a first test, indeed the Sascha Willems triangle with
> -DUSE_D2D_WSI=ON is probably best.
>
> One thing I can add is that most Wayland compositors use OpenGL for
> rendering and will only expose linux dmabuf capability if accelerated
> OpenGL support is found by the compositor. So even if you manage to
> hack some WSI functionality to be exposed by the Vulkan driver, it
> still won't work out of the box with regular compositors since there
> is no zink/OpenGL support yet. There is some experimental Vulkan
> renderer support in some compositors but last time I tried they hit
> other limitations due to the early state of powervr Vulkan in Mesa.
If I disable the GUI, do you think it would render via kms/drm? I was
having issues starting Ubuntu with X11.
>
> I did some work related to this and managed to run a Vulkan triangle
> with Wayland and a modified compositor so far. So at least we could
> get the client side out of the way soon. But that depends on a Mesa
> development branch from Imagination which is being heavily reworked,
> so we need to wait for that rework to make its way into upstream Mesa
> before making progress on that work being upstreamed.
OK. I won't spend any more time on it. I knew the driver was in its
infancy, but I didn't realize how much.
I'll likely push my existing device tree changes to the Geert's
Renesas tree so the GPU node can be added which should make this
easier in the future. I can push my tweak via gitlab, adding
DEF_CONFIG("renesas,r8a774a1-gpu", "renesas,du-r8a774a1"), if you
think that would be accepted.
adam
>
>
> Erico
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Tue, Feb 20, 2024 at 5:26 AM Adam Ford wrote: > > On Tue, Feb 20, 2024 at 3:21 AM Matt Coster wrote: > > > > Hi Adam, > > > > On 19/02/2024 20:38, Adam Ford wrote: > > > On Mon, Feb 19, 2024 at 3:00 AM Matt Coster > > > wrote: > > >> > > >> Hi Adam, > > >> > > >> On 18/02/2024 23:26, Adam Ford wrote: > > >>> On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard > > >>> wrote: > > >>>> > > >>>> On Fri, Feb 16, 2024 at 09:13:14AM +, Biju Das wrote: > > >>>>> Hi Maxime Ripard, > > >>>>> > > >>>>>> -Original Message- > > >>>>>> From: Maxime Ripard > > >>>>>> Sent: Friday, February 16, 2024 9:05 AM > > >>>>>> Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should > > >>>>>> depend on > > >>>>>> ARCH_K3 > > >>>>>> > > >>>>>> On Fri, Feb 16, 2024 at 08:47:46AM +, Biju Das wrote: > > >>>>>>> Hi Adam Ford, > > >>>>>>> > > >>>>>>>> -Original Message- > > >>>>>>>> From: Adam Ford > > >>>>>>>> Sent: Thursday, February 15, 2024 11:36 PM > > >>>>>>>> Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend > > >>>>>>>> on > > >>>>>>>> ARCH_K3 > > >>>>>>>> > > >>>>>>>> On Thu, Feb 15, 2024 at 11:22 AM Adam Ford > > >>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford > > >>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven > > >>>>>>>>>> wrote: > > >>>>>>>>>>> > > >>>>>>>>>>> Hi Maxime, > > >>>>>>>>>>> > > >>>>>>>>>>> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard > > >>>>>>>>>>> > > >>>>>>>> wrote: > > >>>>>>>>>>>> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven > > >>>>>>>> wrote: > > >>>>>>>>>>>>> Using the Imagination Technologies PowerVR Series 6 GPU > > >>>>>>>>>>>>> requires a proprietary firmware image, which is currently > > >>>>>>>>>>>>> only available for Texas Instruments K3 AM62x SoCs. Hence > > >>>>>>>>>>>>> add a dependency on ARCH_K3, to prevent asking the user > > >>>>>>>>>>>>> about this driver when configuring a kernel without Texas > > >>>>>>>>>>>>> Instruments K3 > > >>>>>>>> Multicore SoC support. > > >>>>>>>>>>>> > > >>>>>>>>>>>> This wasn't making sense the first time you sent it, and now > > >>>>>>>>>>>> that commit log is just plain wrong. We have firmwares for > > >>>>>>>>>>>> the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models, > > >>>>>>>>>>>> which can be found on (at least) Renesas, Mediatek, > > >>>>>>>>>>>> Rockchip, TI and StarFive, so across three > > >>>>>>>>>>> > > >>>>>>>>>>> I am so happy to be proven wrong! > > >>>>>>>>>>> Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. > > >>>>>>>>>>> R-Car M3- > > >>>>>>>> W. > > >>>>>>>>>>> > > >>>>>>>>>>>> architectures and 5 platforms. In two months. > > >>>>>>>>>>> > > >>>>>>>>>>> That sounds like great progress, thanks a lot! > > >>>>>>>>>>> > > >>>>>>
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Tue, Feb 20, 2024 at 3:21 AM Matt Coster wrote: > > Hi Adam, > > On 19/02/2024 20:38, Adam Ford wrote: > > On Mon, Feb 19, 2024 at 3:00 AM Matt Coster wrote: > >> > >> Hi Adam, > >> > >> On 18/02/2024 23:26, Adam Ford wrote: > >>> On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard wrote: > >>>> > >>>> On Fri, Feb 16, 2024 at 09:13:14AM +, Biju Das wrote: > >>>>> Hi Maxime Ripard, > >>>>> > >>>>>> -Original Message- > >>>>>> From: Maxime Ripard > >>>>>> Sent: Friday, February 16, 2024 9:05 AM > >>>>>> Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend > >>>>>> on > >>>>>> ARCH_K3 > >>>>>> > >>>>>> On Fri, Feb 16, 2024 at 08:47:46AM +, Biju Das wrote: > >>>>>>> Hi Adam Ford, > >>>>>>> > >>>>>>>> -Original Message- > >>>>>>>> From: Adam Ford > >>>>>>>> Sent: Thursday, February 15, 2024 11:36 PM > >>>>>>>> Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend > >>>>>>>> on > >>>>>>>> ARCH_K3 > >>>>>>>> > >>>>>>>> On Thu, Feb 15, 2024 at 11:22 AM Adam Ford > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford > >>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven > >>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hi Maxime, > >>>>>>>>>>> > >>>>>>>>>>> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard > >>>>>>>>>>> > >>>>>>>> wrote: > >>>>>>>>>>>> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven > >>>>>>>> wrote: > >>>>>>>>>>>>> Using the Imagination Technologies PowerVR Series 6 GPU > >>>>>>>>>>>>> requires a proprietary firmware image, which is currently > >>>>>>>>>>>>> only available for Texas Instruments K3 AM62x SoCs. Hence > >>>>>>>>>>>>> add a dependency on ARCH_K3, to prevent asking the user > >>>>>>>>>>>>> about this driver when configuring a kernel without Texas > >>>>>>>>>>>>> Instruments K3 > >>>>>>>> Multicore SoC support. > >>>>>>>>>>>> > >>>>>>>>>>>> This wasn't making sense the first time you sent it, and now > >>>>>>>>>>>> that commit log is just plain wrong. We have firmwares for > >>>>>>>>>>>> the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models, > >>>>>>>>>>>> which can be found on (at least) Renesas, Mediatek, > >>>>>>>>>>>> Rockchip, TI and StarFive, so across three > >>>>>>>>>>> > >>>>>>>>>>> I am so happy to be proven wrong! > >>>>>>>>>>> Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. > >>>>>>>>>>> R-Car M3- > >>>>>>>> W. > >>>>>>>>>>> > >>>>>>>>>>>> architectures and 5 platforms. In two months. > >>>>>>>>>>> > >>>>>>>>>>> That sounds like great progress, thanks a lot! > >>>>>>>>>>> > >>>>>>>>>> Geert, > >>>>>>>>>> > >>>>>>>>>>> Where can I find these firmwares? Linux-firmware[1] seems to > >>>>>>>>>>> lack all but the original K3 AM62x one. > >>>>>>>>>> > >>>>>>>>>> I think PowerVR has a repo [1], but the last time I checked it, > >>>>>
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Mon, Feb 19, 2024 at 3:00 AM Matt Coster wrote: > > Hi Adam, > > On 18/02/2024 23:26, Adam Ford wrote: > > On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard wrote: > >> > >> On Fri, Feb 16, 2024 at 09:13:14AM +, Biju Das wrote: > >>> Hi Maxime Ripard, > >>> > >>>> -Original Message- > >>>> From: Maxime Ripard > >>>> Sent: Friday, February 16, 2024 9:05 AM > >>>> Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on > >>>> ARCH_K3 > >>>> > >>>> On Fri, Feb 16, 2024 at 08:47:46AM +, Biju Das wrote: > >>>>> Hi Adam Ford, > >>>>> > >>>>>> -Original Message- > >>>>>> From: Adam Ford > >>>>>> Sent: Thursday, February 15, 2024 11:36 PM > >>>>>> Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend > >>>>>> on > >>>>>> ARCH_K3 > >>>>>> > >>>>>> On Thu, Feb 15, 2024 at 11:22 AM Adam Ford wrote: > >>>>>>> > >>>>>>> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford > >>>> wrote: > >>>>>>>> > >>>>>>>> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi Maxime, > >>>>>>>>> > >>>>>>>>> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard > >>>>>>>>> > >>>>>> wrote: > >>>>>>>>>> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven > >>>>>> wrote: > >>>>>>>>>>> Using the Imagination Technologies PowerVR Series 6 GPU > >>>>>>>>>>> requires a proprietary firmware image, which is currently > >>>>>>>>>>> only available for Texas Instruments K3 AM62x SoCs. Hence > >>>>>>>>>>> add a dependency on ARCH_K3, to prevent asking the user > >>>>>>>>>>> about this driver when configuring a kernel without Texas > >>>>>>>>>>> Instruments K3 > >>>>>> Multicore SoC support. > >>>>>>>>>> > >>>>>>>>>> This wasn't making sense the first time you sent it, and now > >>>>>>>>>> that commit log is just plain wrong. We have firmwares for > >>>>>>>>>> the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models, > >>>>>>>>>> which can be found on (at least) Renesas, Mediatek, > >>>>>>>>>> Rockchip, TI and StarFive, so across three > >>>>>>>>> > >>>>>>>>> I am so happy to be proven wrong! > >>>>>>>>> Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. > >>>>>>>>> R-Car M3- > >>>>>> W. > >>>>>>>>> > >>>>>>>>>> architectures and 5 platforms. In two months. > >>>>>>>>> > >>>>>>>>> That sounds like great progress, thanks a lot! > >>>>>>>>> > >>>>>>>> Geert, > >>>>>>>> > >>>>>>>>> Where can I find these firmwares? Linux-firmware[1] seems to > >>>>>>>>> lack all but the original K3 AM62x one. > >>>>>>>> > >>>>>>>> I think PowerVR has a repo [1], but the last time I checked it, > >>>>>>>> the BVNC for the firmware didn't match what was necessary for > >>>>>>>> the GX6250 on the RZ/G2M. I can't remember what the > >>>>>>>> corresponding R-Car3 model is. I haven't tried recently because > >>>>>>>> I was told more documentation for firmware porting would be > >>>>>>>> delayed until everything was pushed into the kernel and Mesa. > >>>>>>>> Maybe there is a better repo and/or newer firmware somewhere else. > >>>>>>>> > >>>>>>> I should have doubled checked the repo contents before I sent my > >>>>>>&g
Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Mon, Feb 19, 2024 at 1:45 AM Biju Das wrote: > > Hi Adam, > > > -Original Message- > > From: Adam Ford > > Sent: Sunday, February 18, 2024 11:26 PM > > Subject: Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend > > on ARCH_K3 > > > > On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard wrote: > > > > > > On Fri, Feb 16, 2024 at 09:13:14AM +, Biju Das wrote: > > > > Hi Maxime Ripard, > > > > > > > > > -Original Message- > > > > > From: Maxime Ripard > > > > > Sent: Friday, February 16, 2024 9:05 AM > > > > > Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should > > > > > depend on > > > > > ARCH_K3 > > > > > > > > > > On Fri, Feb 16, 2024 at 08:47:46AM +, Biju Das wrote: > > > > > > Hi Adam Ford, > > > > > > > > > > > > > -Original Message- > > > > > > > From: Adam Ford > > > > > > > Sent: Thursday, February 15, 2024 11:36 PM > > > > > > > Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should > > > > > > > depend on > > > > > > > ARCH_K3 > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 11:22 AM Adam Ford > > wrote: > > > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Maxime, > > > > > > > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert > > > > > > > > > > > Uytterhoeven > > > > > > > wrote: > > > > > > > > > > > > Using the Imagination Technologies PowerVR Series 6 > > > > > > > > > > > > GPU requires a proprietary firmware image, which is > > > > > > > > > > > > currently only available for Texas Instruments K3 > > > > > > > > > > > > AM62x SoCs. Hence add a dependency on ARCH_K3, to > > > > > > > > > > > > prevent asking the user about this driver when > > > > > > > > > > > > configuring a kernel without Texas Instruments K3 > > > > > > > Multicore SoC support. > > > > > > > > > > > > > > > > > > > > > > This wasn't making sense the first time you sent it, > > > > > > > > > > > and now that commit log is just plain wrong. We have > > > > > > > > > > > firmwares for the G6110, GX6250, GX6650, BXE-4-32, and > > > > > > > > > > > BXS-4-64 models, which can be found on (at least) > > > > > > > > > > > Renesas, Mediatek, Rockchip, TI and StarFive, so > > > > > > > > > > > across three > > > > > > > > > > > > > > > > > > > > I am so happy to be proven wrong! > > > > > > > > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. > > > > > > > > > > R-Car M3- > > > > > > > W. > > > > > > > > > > > > > > > > > > > > > architectures and 5 platforms. In two months. > > > > > > > > > > > > > > > > > > > > That sounds like great progress, thanks a lot! > > > > > > > > > > > > > > > > > > > Geert, > > > > > > > > > > > > > > > > > > > Where can I find these firmwares? Linux-firmware[1] > > > > > > > > > > seems to lack all but the original K3 AM62x one. > > > > > > > > > > > > > > > > > > I think PowerVR has a repo [1], but the last time I > > >
Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard wrote: > > On Fri, Feb 16, 2024 at 09:13:14AM +, Biju Das wrote: > > Hi Maxime Ripard, > > > > > -Original Message- > > > From: Maxime Ripard > > > Sent: Friday, February 16, 2024 9:05 AM > > > Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on > > > ARCH_K3 > > > > > > On Fri, Feb 16, 2024 at 08:47:46AM +, Biju Das wrote: > > > > Hi Adam Ford, > > > > > > > > > -Original Message- > > > > > From: Adam Ford > > > > > Sent: Thursday, February 15, 2024 11:36 PM > > > > > Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend > > > > > on > > > > > ARCH_K3 > > > > > > > > > > On Thu, Feb 15, 2024 at 11:22 AM Adam Ford wrote: > > > > > > > > > > > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford > > > wrote: > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Maxime, > > > > > > > > > > > > > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard > > > > > > > > > > > > > wrote: > > > > > > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven > > > > > wrote: > > > > > > > > > > Using the Imagination Technologies PowerVR Series 6 GPU > > > > > > > > > > requires a proprietary firmware image, which is currently > > > > > > > > > > only available for Texas Instruments K3 AM62x SoCs. Hence > > > > > > > > > > add a dependency on ARCH_K3, to prevent asking the user > > > > > > > > > > about this driver when configuring a kernel without Texas > > > > > > > > > > Instruments K3 > > > > > Multicore SoC support. > > > > > > > > > > > > > > > > > > This wasn't making sense the first time you sent it, and now > > > > > > > > > that commit log is just plain wrong. We have firmwares for > > > > > > > > > the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models, > > > > > > > > > which can be found on (at least) Renesas, Mediatek, > > > > > > > > > Rockchip, TI and StarFive, so across three > > > > > > > > > > > > > > > > I am so happy to be proven wrong! > > > > > > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. > > > > > > > > R-Car M3- > > > > > W. > > > > > > > > > > > > > > > > > architectures and 5 platforms. In two months. > > > > > > > > > > > > > > > > That sounds like great progress, thanks a lot! > > > > > > > > > > > > > > > Geert, > > > > > > > > > > > > > > > Where can I find these firmwares? Linux-firmware[1] seems to > > > > > > > > lack all but the original K3 AM62x one. > > > > > > > > > > > > > > I think PowerVR has a repo [1], but the last time I checked it, > > > > > > > the BVNC for the firmware didn't match what was necessary for > > > > > > > the GX6250 on the RZ/G2M. I can't remember what the > > > > > > > corresponding R-Car3 model is. I haven't tried recently because > > > > > > > I was told more documentation for firmware porting would be > > > > > > > delayed until everything was pushed into the kernel and Mesa. > > > > > > > Maybe there is a better repo and/or newer firmware somewhere else. > > > > > > > > > > > > > I should have doubled checked the repo contents before I sent my > > > > > > last e-mail , but it appears the firmware [2] for the RZ/G2M, > > > > > > might be present now. I don't know if there are driver updates > > > > > > necessary. I checked my e-mails, but I didn't see any > > > > > > notification, or I would have tried it earlier. Either way, thank > > > > > > you Frank for adding it. I'll tr
Re: [PATCH V8 09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
On Fri, Feb 16, 2024 at 3:05 AM Alexander Stein
wrote:
>
> Hi all,
>
> Am Samstag, 3. Februar 2024, 17:52:49 CET schrieb Adam Ford:
> > From: Lucas Stach
> >
> > The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
> > core with a little bit of SoC integration around it.
> >
> > Signed-off-by: Lucas Stach
> > Signed-off-by: Adam Ford
> >
> > ---
> > V3: Change name and location to better idenfity as a bridge and
> > HDMI 2.0a transmitter
> >
> > Fix typos and feedback from Rob and added ports.
> > ---
> > .../display/bridge/fsl,imx8mp-hdmi-tx.yaml| 102 ++
> > 1 file changed, 102 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > new file mode 100644
> > index ..3791c9f4ebab
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > @@ -0,0 +1,102 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/fsl,imx8mp-hdmi-tx.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Freescale i.MX8MP DWC HDMI TX Encoder
> > +
> > +maintainers:
> > + - Lucas Stach
> > +
> > +description:
> > + The i.MX8MP HDMI transmitter is a Synopsys DesignWare
> > + HDMI 2.0a TX controller IP.
> > +
> > +allOf:
> > + - $ref: /schemas/display/bridge/synopsys,dw-hdmi.yaml#
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - fsl,imx8mp-hdmi-tx
> > +
> > + reg-io-width:
> > +const: 1
> > +
> > + clocks:
> > +maxItems: 4
> > +
> > + clock-names:
> > +items:
> > + - const: iahb
> > + - const: isfr
> > + - const: cec
> > + - const: pix
> > +
> > + power-domains:
> > +maxItems: 1
> > +
> > + ports:
> > +$ref: /schemas/graph.yaml#/properties/ports
> > +
> > +properties:
> > + port@0:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: Parallel RGB input port
> > +
> > + port@1:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: HDMI output port
> > +
> > +required:
> > + - port@0
> > + - port@1
>
> Is this really correct that port@1 is required? AFAICS this host already
> supports HPD and DDC by itself, so there is no need for a dedicated HDMI
> connector.
> With the current state of the drivers this output port is completely ignored
> anyway. Yet it works for a lot of people.
One of the feedback responses Lucas got was that it was missing the
reference to the HDMI connector, so I added it as a response to that
feedback. I have tried device trees with and without it, and it
doesn't impact anything, but It seems like there may be a requirement
for it.
adam
>
> Best regards,
> Alexander
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > + - interrupts
> > + - power-domains
> > + - ports
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +#include
> > +
> > +hdmi@32fd8000 {
> > +compatible = "fsl,imx8mp-hdmi-tx";
> > +reg = <0x32fd8000 0x7eff>;
> > +interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> > +clocks = < IMX8MP_CLK_HDMI_APB>,
> > + < IMX8MP_CLK_HDMI_REF_266M>,
> > + < IMX8MP_CLK_32K>,
> > + <_tx_phy>;
> > +clock-names = "iahb", "isfr", "cec", "pix";
> > +power-domains = <_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>;
> > +reg-io-width = <1>;
> > +ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + port@0 {
> > + reg = <0>;
> > +
> > + hdmi_tx_from_pvi: endpoint {
> > + remote-endpoint = <_to_hdmi_tx>;
> > + };
> > + };
> > +
> > + port@1 {
> > +reg = <1>;
> > + hdmi_tx_out: endpoint {
> > +remote-endpoint = <_con>;
> > + };
> > + };
> > +};
> > +};
>
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> http://www.tq-group.com/
>
>
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Thu, Feb 15, 2024 at 11:22 AM Adam Ford wrote:
>
> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford wrote:
> >
> > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > wrote:
> > >
> > > Hi Maxime,
> > >
> > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard wrote:
> > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > > > proprietary firmware image, which is currently only available for
> > > > > Texas
> > > > > Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to
> > > > > prevent asking the user about this driver when configuring a kernel
> > > > > without Texas Instruments K3 Multicore SoC support.
> > > >
> > > > This wasn't making sense the first time you sent it, and now that commit
> > > > log is just plain wrong. We have firmwares for the G6110, GX6250,
> > > > GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> > > > Renesas, Mediatek, Rockchip, TI and StarFive, so across three
> > >
> > > I am so happy to be proven wrong!
> > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
> > >
> > > > architectures and 5 platforms. In two months.
> > >
> > > That sounds like great progress, thanks a lot!
> > >
> > Geert,
> >
> > > Where can I find these firmwares? Linux-firmware[1] seems to lack all
> > > but the original K3 AM62x one.
> >
> > I think PowerVR has a repo [1], but the last time I checked it, the
> > BVNC for the firmware didn't match what was necessary for the GX6250
> > on the RZ/G2M. I can't remember what the corresponding R-Car3 model
> > is. I haven't tried recently because I was told more documentation
> > for firmware porting would be delayed until everything was pushed into
> > the kernel and Mesa. Maybe there is a better repo and/or newer
> > firmware somewhere else.
> >
> I should have doubled checked the repo contents before I sent my last
> e-mail , but it appears the firmware [2] for the RZ/G2M, might be
> present now. I don't know if there are driver updates necessary. I
> checked my e-mails, but I didn't see any notification, or I would have
> tried it earlier. Either way, thank you Frank for adding it. I'll
> try to test when I have some time.
>
I don't have the proper version of Mesa setup yet, but for what it's
worth, the firmware loads without error, and it doesn't hang.
[9.787836] powervr fd00.gpu: [drm] loaded firmware
powervr/rogue_4.45.2.58_v1.fw
[9.787861] powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
adam
> > adam
> >
> > [1]
> > https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr/powervr?ref_type=heads
>
> [2] -
> https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b
>
> >
> >
> > >
> > > Thanks again!
> > >
> > > [1]
> > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> > >
> > > Gr{oetje,eeting}s,
> > >
> > > Geert
> > >
> > > --
> > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> > > ge...@linux-m68k.org
> > >
> > > In personal conversations with technical people, I call myself a hacker.
> > > But
> > > when I'm talking to journalists I just say "programmer" or something like
> > > that.
> > > -- Linus Torvalds
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Thu, Feb 15, 2024 at 11:10 AM Adam Ford wrote:
>
> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> wrote:
> >
> > Hi Maxime,
> >
> > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard wrote:
> > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > > proprietary firmware image, which is currently only available for Texas
> > > > Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to
> > > > prevent asking the user about this driver when configuring a kernel
> > > > without Texas Instruments K3 Multicore SoC support.
> > >
> > > This wasn't making sense the first time you sent it, and now that commit
> > > log is just plain wrong. We have firmwares for the G6110, GX6250,
> > > GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> > > Renesas, Mediatek, Rockchip, TI and StarFive, so across three
> >
> > I am so happy to be proven wrong!
> > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
> >
> > > architectures and 5 platforms. In two months.
> >
> > That sounds like great progress, thanks a lot!
> >
> Geert,
>
> > Where can I find these firmwares? Linux-firmware[1] seems to lack all
> > but the original K3 AM62x one.
>
> I think PowerVR has a repo [1], but the last time I checked it, the
> BVNC for the firmware didn't match what was necessary for the GX6250
> on the RZ/G2M. I can't remember what the corresponding R-Car3 model
> is. I haven't tried recently because I was told more documentation
> for firmware porting would be delayed until everything was pushed into
> the kernel and Mesa. Maybe there is a better repo and/or newer
> firmware somewhere else.
>
I should have doubled checked the repo contents before I sent my last
e-mail , but it appears the firmware [2] for the RZ/G2M, might be
present now. I don't know if there are driver updates necessary. I
checked my e-mails, but I didn't see any notification, or I would have
tried it earlier. Either way, thank you Frank for adding it. I'll
try to test when I have some time.
> adam
>
> [1]
> https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr/powervr?ref_type=heads
[2] -
https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b
>
>
> >
> > Thanks again!
> >
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> > ge...@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like
> > that.
> > -- Linus Torvalds
Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
wrote:
>
> Hi Maxime,
>
> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard wrote:
> > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > proprietary firmware image, which is currently only available for Texas
> > > Instruments K3 AM62x SoCs. Hence add a dependency on ARCH_K3, to
> > > prevent asking the user about this driver when configuring a kernel
> > > without Texas Instruments K3 Multicore SoC support.
> >
> > This wasn't making sense the first time you sent it, and now that commit
> > log is just plain wrong. We have firmwares for the G6110, GX6250,
> > GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> > Renesas, Mediatek, Rockchip, TI and StarFive, so across three
>
> I am so happy to be proven wrong!
> Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
>
> > architectures and 5 platforms. In two months.
>
> That sounds like great progress, thanks a lot!
>
Geert,
> Where can I find these firmwares? Linux-firmware[1] seems to lack all
> but the original K3 AM62x one.
I think PowerVR has a repo [1], but the last time I checked it, the
BVNC for the firmware didn't match what was necessary for the GX6250
on the RZ/G2M. I can't remember what the corresponding R-Car3 model
is. I haven't tried recently because I was told more documentation
for firmware porting would be delayed until everything was pushed into
the kernel and Mesa. Maybe there is a better repo and/or newer
firmware somewhere else.
adam
[1]
https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr/powervr?ref_type=heads
>
> Thanks again!
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
[PATCH V2 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding
When using video sync pulses, the HFP, HBP, and HSA are divided between
the available lanes if there is more than one lane. For certain
timings and lane configurations, the HFP may not be evenly divisible.
If the HFP is rounded down, it ends up being too small which can cause
some monitors to not sync properly. In these instances, adjust htotal
and hsync to round the HFP up, and recalculate the htotal.
Tested-by: Frieder Schrempf # Kontron BL i.MX8MM
with HDMI monitor
Signed-off-by: Adam Ford
---
V2: No changes
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 8476650c477c..52939211fe93 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1606,6 +1606,27 @@ static int samsung_dsim_atomic_check(struct drm_bridge
*bridge,
adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
DRM_MODE_FLAG_PVSYNC);
}
+ /*
+* When using video sync pulses, the HFP, HBP, and HSA are divided
between
+* the available lanes if there is more than one lane. For certain
+* timings and lane configurations, the HFP may not be evenly divisible.
+* If the HFP is rounded down, it ends up being too small which can
cause
+* some monitors to not sync properly. In these instances, adjust htotal
+* and hsync to round the HFP up, and recalculate the htotal. Through
trial
+* and error, it appears that the HBP and HSA do not appearto need the
same
+* correction that HFP does.
+*/
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes > 1)
{
+ int hfp = adjusted_mode->hsync_start - adjusted_mode->hdisplay;
+ int remainder = hfp % dsi->lanes;
+
+ if (remainder) {
+ adjusted_mode->hsync_start += remainder;
+ adjusted_mode->hsync_end += remainder;
+ adjusted_mode->htotal += remainder;
+ }
+ }
+
return 0;
}
--
2.43.0
[PATCH V2 1/2] drm/bridge: samsung-dsim: Set P divider based on min/max of fin pll
The P divider should be set based on the min and max values of
the fin pll which may vary between different platforms.
These ranges are defined per platform, but hard-coded values
were used instead which resulted in a smaller range available
on the i.MX8M[MNP] than what was possible.
As noted by Frieder, there are descripencies between the reference
manuals of the Mini, Nano and Plus, so I reached out to my NXP
rep and got the following response regarding the varing notes
in the documentation.
"Yes it is definitely wrong, the one that is part of the NOTE in
MIPI_DPHY_M_PLLPMS register table against PMS_P, PMS_M and PMS_S is
not correct. I will report this to Doc team, the one customer should
be take into account is the Table 13-40 DPHY PLL Parameters and the
Note above."
With this patch, the clock rates now match the values used in NXP's
downstream kernel.
Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock")
Signed-off-by: Adam Ford
Reviewed-by: Frieder Schrempf
Tested-by: Frieder Schrempf
---
V2: Only update the commit message to reflect why these values
were chosen. No code change present
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 95fedc68b0ae..8476650c477c 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -574,8 +574,8 @@ static unsigned long samsung_dsim_pll_find_pms(struct
samsung_dsim *dsi,
u16 _m, best_m;
u8 _s, best_s;
- p_min = DIV_ROUND_UP(fin, (12 * MHZ));
- p_max = fin / (6 * MHZ);
+ p_min = DIV_ROUND_UP(fin, (driver_data->pll_fin_max * MHZ));
+ p_max = fin / (driver_data->pll_fin_min * MHZ);
for (_p = p_min; _p <= p_max; ++_p) {
for (_s = 0; _s <= 5; ++_s) {
--
2.43.0
Re: [PATCH 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding
On Mon, Jan 29, 2024 at 2:17 AM Frieder Schrempf wrote: > > On 25.01.24 19:44, Adam Ford wrote: > > On Mon, Dec 11, 2023 at 9:33 PM Adam Ford wrote: > >> > >> When using video sync pulses, the HFP, HBP, and HSA are divided between > >> the available lanes if there is more than one lane. For certain > >> timings and lane configurations, the HFP may not be evenly divisible. > >> If the HFP is rounded down, it ends up being too small which can cause > >> some monitors to not sync properly. In these instances, adjust htotal > >> and hsync to round the HFP up, and recalculate the htotal. > >> > >> Tested-by: Frieder Schrempf # Kontron BL > >> i.MX8MM with HDMI monitor > >> Signed-off-by: Adam Ford > > > > Gentle nudge on this one. Basically this fixes an issue with the 8MP, > > but it's still unknown why it doesn't work on 8MM or 8MN, but Frieder > > confirmed there are no regressions on 8MM or 8MN. > Inki, Is there something you need which is holding this back? It's been nearly two months since I posted the initial patch. Thank you, adam > I only tested two specific display setups on i.MX8MM. So of course I > can't confirm the absence of regressions in general. > > Anyway, I think this should be applied.
Re: [PATCH] drm/bridge: imx8mp-hdmi-pvi: Fix build warnings
On Wed, Feb 7, 2024 at 3:24 AM Neil Armstrong wrote:
>
> On 07/02/2024 10:22, Fabio Estevam wrote:
> > Hi Adam,
> >
> > On Tue, Feb 6, 2024 at 9:23 PM Adam Ford wrote:
> >>
> >> Two separate build warnings were reported. One from an
> >> uninitialized variable, and the other from returning 0
> >> instead of NULL from a pointer.
> >>
> >> Fixes: 059c53e877ca ("drm/bridge: imx: add driver for HDMI TX Parallel
> >> Video Interface")
> >> Reported-by: nat...@kernel.org
> >
> > The Reported-by line format can be improved:
> >
Sorry about .that
> > Reported-by: Nathan Chancellor
> >
> > Thanks
>
> Fixed while applying,
Thank you!
adam
>
> Thanks,
> Neil
[PATCH] drm/bridge: imx8mp-hdmi-pvi: Fix build warnings
Two separate build warnings were reported. One from an
uninitialized variable, and the other from returning 0
instead of NULL from a pointer.
Fixes: 059c53e877ca ("drm/bridge: imx: add driver for HDMI TX Parallel Video
Interface")
Reported-by: nat...@kernel.org
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202402062134.a6cqat3s-...@intel.com/
Signed-off-by: Adam Ford
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
index a76b7669fe8a..f2a09c879e3d 100644
--- a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
@@ -57,7 +57,7 @@ static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge
*bridge,
const struct drm_display_mode *mode;
struct drm_crtc_state *crtc_state;
struct drm_connector *connector;
- u32 bus_flags, val;
+ u32 bus_flags = 0, val;
connector = drm_atomic_get_new_connector_for_encoder(state,
bridge->encoder);
conn_state = drm_atomic_get_new_connector_state(state, connector);
@@ -110,7 +110,7 @@ imx8mp_hdmi_pvi_bridge_get_input_bus_fmts(struct drm_bridge
*bridge,
struct drm_bridge_state *next_state;
if (!next_bridge->funcs->atomic_get_input_bus_fmts)
- return 0;
+ return NULL;
next_state = drm_atomic_get_new_bridge_state(crtc_state->state,
next_bridge);
--
2.43.0
Re: [PATCH V8 08/12] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
On Tue, Feb 6, 2024 at 11:06 AM Nathan Chancellor wrote:
>
> Hi all,
>
> On Sat, Feb 03, 2024 at 10:52:48AM -0600, Adam Ford wrote:
> > From: Lucas Stach
> >
> > This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
> > full timing generator and can switch between different video sources. On
> > the i.MX8MP however the only supported source is the LCDIF. The block
> > just needs to be powered up and told about the polarity of the video
> > sync signals to act in bypass mode.
> >
> > Signed-off-by: Lucas Stach
> > Reviewed-by: Luca Ceresoli (v7)
> > Tested-by: Marek Vasut (v1)
> > Tested-by: Luca Ceresoli (v7)
> > Tested-by: Richard Leitner (v2)
> > Tested-by: Frieder Schrempf (v2)
> > Reviewed-by: Laurent Pinchart (v3)
> > Reviewed-by: Luca Ceresoli
> > Tested-by: Luca Ceresoli
> > Tested-by: Fabio Estevam
> > Signed-off-by: Adam Ford
>
>
>
> > diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > new file mode 100644
> > index ..a76b7669fe8a
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> ...
> > +static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
> > + struct drm_bridge_state
> > *bridge_state)
> > +{
> > + struct drm_atomic_state *state = bridge_state->base.state;
> > + struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> > + struct drm_connector_state *conn_state;
> > + const struct drm_display_mode *mode;
> > + struct drm_crtc_state *crtc_state;
> > + struct drm_connector *connector;
> > + u32 bus_flags, val;
> > +
> > + connector = drm_atomic_get_new_connector_for_encoder(state,
> > bridge->encoder);
> > + conn_state = drm_atomic_get_new_connector_state(state, connector);
> > + crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
> > +
> > + if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
> > + return;
> > +
> > + mode = _state->adjusted_mode;
> > +
> > + val = FIELD_PREP(PVI_CTRL_MODE_MASK, PVI_CTRL_MODE_LCDIF) |
> > PVI_CTRL_EN;
> > +
> > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > + val |= PVI_CTRL_OP_VSYNC_POL | PVI_CTRL_INP_VSYNC_POL;
> > +
> > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > + val |= PVI_CTRL_OP_HSYNC_POL | PVI_CTRL_INP_HSYNC_POL;
> > +
> > + if (pvi->next_bridge->timings)
> > + bus_flags = pvi->next_bridge->timings->input_bus_flags;
> > + else if (bridge_state)
> > + bus_flags = bridge_state->input_bus_cfg.flags;
> > +
> > + if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
> > + val |= PVI_CTRL_OP_DE_POL | PVI_CTRL_INP_DE_POL;
> > +
> > + writel(val, pvi->regs + HTX_PVI_CTRL);
> > +}
>
> Apologies if this has already been reported or fixed, I searched lore
> and did not find anything. Clang warns (or errors with CONFIG_WERROR=y)
> for this function:
>
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:81:11: error: variable
> 'bus_flags' is used uninitialized whenever 'if' condition is false
> [-Werror,-Wsometimes-uninitialized]
> 81 | else if (bridge_state)
> | ^~~~
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:84:6: note: uninitialized use
> occurs here
> 84 | if (bus_flags & DRM_BUS_FLAG_DE_HIGH)
> | ^
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:81:7: note: remove the 'if' if
> its condition is always true
> 81 | else if (bridge_state)
> | ^
> 82 | bus_flags = bridge_state->input_bus_cfg.flags;
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c:60:15: note: initialize the
> variable 'bus_flags' to silence this warning
> 60 | u32 bus_flags, val;
> | ^
> | = 0
> 1 error generated.
>
> This seems legitimate. If bridge_state can be NULL, should bus_flags be
> initialized to zero like it suggests or should that 'else if' be turned
> into a plain 'else'? I am happy to send a patch with that guidance.
I don't think we can turn the else-if into a blind else, because in
order to make bus_flags point to bridge_state->input_bus_cfg.flags,
bridge_state must not be NULL, but we could add an additional else to
set bus_flags to 0, but I think the simplest thing to do would be to
set bus_flags = 0 at the initialization on line 60 as it suggests.
If you agree, I can submit a patch later tonight. I need to fix
another issue found by the build-bot [1] to make line 113 return NULL
instead of 0 anyway. I figured I could just fix them both at the same
time.
adam
[1] - https://lore.kernel.org/oe-kbuild-all/202402062134.a6cqat3s-...@intel.com/
>
> Cheers,
> Nathan
Re: [PATCH V8 02/12] phy: freescale: add Samsung HDMI PHY
On Mon, Feb 5, 2024 at 2:17 AM Marco Felsch wrote:
>
> On 24-02-04, Dmitry Baryshkov wrote:
> > On Sat, 3 Feb 2024 at 17:53, Adam Ford wrote:
> > >
> > > From: Lucas Stach
> > >
> > > This adds the driver for the Samsung HDMI PHY found on the
> > > i.MX8MP SoC.
> > >
> > > Signed-off-by: Lucas Stach
> > > Signed-off-by: Adam Ford
> > > Tested-by: Alexander Stein
> > > ---
> > > V4: Make lookup table hex values lower case.
> > >
> > > V3: Re-order the Makefile to keep it alphabetical
> > > Remove unused defines
> > >
> > > V2: Fixed some whitespace found from checkpatch
> > > Change error handling when enabling apbclk to use dev_err_probe
> > > Rebase on Linux-Next
> > >
> > > I (Adam) tried to help move this along, so I took Lucas' patch and
> > > attempted to apply fixes based on feedback. I don't have
> > > all the history, so apologies for that.
> > > ---
> > > drivers/phy/freescale/Kconfig|6 +
> > > drivers/phy/freescale/Makefile |1 +
> > > drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 ++
> > > 3 files changed, 1082 insertions(+)
> > > create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > >
> > > diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> > > index 853958fb2c06..5c2b73042dfc 100644
> > > --- a/drivers/phy/freescale/Kconfig
> > > +++ b/drivers/phy/freescale/Kconfig
> > > @@ -35,6 +35,12 @@ config PHY_FSL_IMX8M_PCIE
> > > Enable this to add support for the PCIE PHY as found on
> > > i.MX8M family of SOCs.
> > >
> > > +config PHY_FSL_SAMSUNG_HDMI_PHY
> > > + tristate "Samsung HDMI PHY support"
> > > + depends on OF && HAS_IOMEM
> > > + help
> > > + Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
> > > +
> > > endif
> > >
> > > config PHY_FSL_LYNX_28G
> > > diff --git a/drivers/phy/freescale/Makefile
> > > b/drivers/phy/freescale/Makefile
> > > index cedb328bc4d2..79e5f16d3ce8 100644
> > > --- a/drivers/phy/freescale/Makefile
> > > +++ b/drivers/phy/freescale/Makefile
> > > @@ -4,3 +4,4 @@ obj-$(CONFIG_PHY_MIXEL_LVDS_PHY)+=
> > > phy-fsl-imx8qm-lvds-phy.o
> > > obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += phy-fsl-imx8-mipi-dphy.o
> > > obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o
> > > obj-$(CONFIG_PHY_FSL_LYNX_28G) += phy-fsl-lynx-28g.o
> > > +obj-$(CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY) += phy-fsl-samsung-hdmi.o
> > > diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > new file mode 100644
> > > index ..bf0e2299d00f
> > > --- /dev/null
> > > +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > > @@ -0,0 +1,1075 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright 2020 NXP
> > > + * Copyright 2022 Pengutronix, Lucas Stach
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#define PHY_REG_33 0x84
> > > +#define REG33_MODE_SET_DONE BIT(7)
> > > +#define REG33_FIX_DA BIT(1)
> > > +
> > > +#define PHY_REG_34 0x88
> > > +#define REG34_PHY_READY BIT(7)
> > > +#define REG34_PLL_LOCKBIT(6)
> > > +#define REG34_PHY_CLK_READY BIT(5)
> > > +
> > > +
> > > +#define PHY_PLL_REGS_NUM 48
> > > +
> > > +struct phy_config {
> > > + u32 clk_rate;
> > > + u8 regs[PHY_PLL_REGS_NUM];
> > > +};
> > > +
> > > +const struct phy_config phy_pll_cfg[] = {
> > > + { 2225, {
> > > + 0x00, 0xd1, 0x4b, 0xf1, 0x89, 0x88, 0x80, 0x40,
> > > + 0x4f, 0x30, 0x33, 0x65, 0x00, 0x15, 0x25, 0x80,
> > > + 0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
> > > + 0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> > >
Re: [PATCH V8 05/12] arm64: dts: imx8mp: add HDMI power-domains
On Mon, Feb 5, 2024 at 1:26 AM Alexander Stein
wrote:
>
> Hi Adam,
>
> thanks for working on this.
>
> Am Samstag, 3. Februar 2024, 17:52:45 CET schrieb Adam Ford:
> > From: Lucas Stach
> >
> > This adds the PGC and HDMI blk-ctrl nodes providing power control for
> > HDMI subsystem peripherals.
> >
> > Signed-off-by: Adam Ford
> > Signed-off-by: Lucas Stach
> > ---
> > V2: Add missing power-domains hdcp and hrv
> > ---
> > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 38 +++
> > 1 file changed, 38 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mp.dtsi index
> > 76c73daf546b..5c54073de615 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > @@ -836,6 +836,23 @@ pgc_mediamix: power-domain@10 {
> ><
> IMX8MP_CLK_MEDIA_APB_ROOT>;
> > };
> >
> > + pgc_hdmimix: power-
> domains@14 {
>
Alexander,
Thanks for the feedback.
> As per Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml the node
> should be called power-domain@.
>
> > + #power-domain-
> cells = <0>;
> > + reg =
> ;
> > + clocks = <
> IMX8MP_CLK_HDMI_ROOT>,
> > + <
> IMX8MP_CLK_HDMI_APB>;
> > + assigned-clocks =
> < IMX8MP_CLK_HDMI_AXI>,
> > +
> < IMX8MP_CLK_HDMI_APB>;
> > + assigned-clock-
> parents = < IMX8MP_SYS_PLL2_500M>,
> > +
> < IMX8MP_SYS_PLL1_133M>;
> > + assigned-clock-
> rates = <5>, <13300>;
> > + };
> > +
> > + pgc_hdmi_phy: power-
> domains@15 {
>
> As per Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml the node
> should be called power-domain@.
Whoops. I totally missed these when I applied them. I'll have them
fixed on the next spin.
>
> > + #power-domain-
> cells = <0>;
> > + reg =
> ;
> > + };
> > +
> > pgc_mipi_phy2: power-
> domain@16 {
> > #power-domain-
> cells = <0>;
> > reg =
> ;
> > @@ -1361,6 +1378,27 @@ eqos: ethernet@30bf {
> > intf_mode = < 0x4>;
> > status = "disabled";
> > };
> > +
> > + hdmi_blk_ctrl: blk-ctrl@32fc {
> > + compatible = "fsl,imx8mp-hdmi-blk-
> ctrl", "syscon";
> > + reg = <0x32fc 0x23c>;
> > + clocks = < IMX8MP_CLK_HDMI_APB>,
> > + <
> IMX8MP_CLK_HDMI_ROOT>,
> > + <
> IMX8MP_CLK_HDMI_REF_266M>,
> > + < IMX8MP_CLK_HDMI_24M>,
> > + <
> IMX8MP_CLK_HDMI_FDCC_TST>;
> > + clock-names = "apb", "axi",
> "ref_266m", "ref_24m", "fdcc";
> > + power-domains = <_hdmimix>,
> <_hdmimix>,
> > + <_hdmimix>,
> <_hdmimix>,
> > + <_hdmimix>,
> <_hdmimix>,
> > + <_hdmimix>,
> <_hdmi_phy>,
> > + <_hdmimix>,
> <_hdmimix>;
> > + power-domain-names = "bus",
> "irqsteer", "lcdif",
> > + "pai", "pvi",
> "trng",
> > + "hdmi-tx",
> "hdmi-tx-phy",
> > + "hdcp",
> "hrv";
> > + #power-domain-cells = <1>;
> > + };
> > };
> >
>
> According to RM this block is part of AIPS4, so it should be below
> hsio_blk_ctrl.
This is how it was when I got it, but I should have caught it. Thanks
for that. It looks like the subsequent HDMI, IRQ_steerting, LCDIF and
PHY ones are also out of place.
adam
>
> Best regards,
> Alexander
>
> > aips5: bus@30c0 {
>
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> http://www.tq-group.com/
>
>
Re: [PATCH V8 06/12] arm64: dts: imx8mp: add HDMI irqsteer
On Sun, Feb 4, 2024 at 6:00 AM Francesco Dolcini wrote: > > On Sat, Feb 03, 2024 at 10:52:46AM -0600, Adam Ford wrote: > > From: Lucas Stach > > > > The HDMI irqsteer is a secondary interrupt controller within the HDMI > > subsystem that maps all HDMI peripheral IRQs into a single upstream > > IRQ line. > > > > Signed-off-by: Lucas Stach > > This is missing your signed-off-by, and in other patches of this series Opps. I thought I caught all those. > your signed-off-by is not the last, as it should be. > > Please have a look and fix this and the other instances. > OK. I have some work to do on some other portions, so I'll clean up that too. adam > Thanks for this work! Thanks for the feedback. adam > > Francesco >
[PATCH V8 12/12] arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module
The i.MX8M Plus has support for an HDMI transmitter. The video is genereated by lcdif3, routed to the hdmi parallel video interface, then fed to a DW HDMI bridge to support up to 4K video output. Signed-off-by: Adam Ford --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index e6cf3e5d63c3..3e33825f0ed7 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -880,6 +880,7 @@ CONFIG_DRM_ANALOGIX_ANX7625=m CONFIG_DRM_I2C_ADV7511=m CONFIG_DRM_I2C_ADV7511_AUDIO=y CONFIG_DRM_CDNS_MHDP8546=m +CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE=m CONFIG_DRM_DW_HDMI_AHB_AUDIO=m CONFIG_DRM_DW_HDMI_CEC=m CONFIG_DRM_IMX_DCSS=m -- 2.43.0
[PATCH V8 11/12] arm64: dts: imx8mp: add HDMI display pipeline
From: Lucas Stach
This adds the DT nodes for all the peripherals that make up the
HDMI display pipeline.
Signed-off-by: Lucas Stach
Signed-off-by: Adam Ford
---
V2: I took this from Lucas' original submission with the following:
Removed extra clock from HDMI-TX since it is now part of the
power domain
Added interrupt-parent to PVI
Changed the name of the HDMI tranmitter to fsl,imx8mp-hdmi-tx
Added ports to HDMI-tx
---
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 94 +++
1 file changed, 94 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 5e51a766f3d9..e84b4f40e570 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -1412,6 +1412,100 @@ irqsteer_hdmi: interrupt-controller@32fc2000 {
clock-names = "ipg";
power-domains = <_blk_ctrl
IMX8MP_HDMIBLK_PD_IRQSTEER>;
};
+
+ hdmi_pvi: display-bridge@32fc4000 {
+ compatible = "fsl,imx8mp-hdmi-pvi";
+ reg = <0x32fc4000 0x40>;
+ interrupt-parent = <_hdmi>;
+ interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <_blk_ctrl
IMX8MP_HDMIBLK_PD_PVI>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ pvi_from_lcdif3: endpoint {
+ remote-endpoint =
<_to_pvi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ pvi_to_hdmi_tx: endpoint {
+ remote-endpoint =
<_tx_from_pvi>;
+ };
+ };
+ };
+ };
+
+ lcdif3: display-controller@32fc6000 {
+ compatible = "fsl,imx8mp-lcdif";
+ reg = <0x32fc6000 0x238>;
+ interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <_hdmi>;
+ clocks = <_tx_phy>,
+< IMX8MP_CLK_HDMI_APB>,
+< IMX8MP_CLK_HDMI_ROOT>;
+ clock-names = "pix", "axi", "disp_axi";
+ power-domains = <_blk_ctrl
IMX8MP_HDMIBLK_PD_LCDIF>;
+
+ port {
+ lcdif3_to_pvi: endpoint {
+ remote-endpoint =
<_from_lcdif3>;
+ };
+ };
+ };
+
+ hdmi_tx: hdmi@32fd8000 {
+ compatible = "fsl,imx8mp-hdmi-tx";
+ reg = <0x32fd8000 0x7eff>;
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <_hdmi>;
+ clocks = < IMX8MP_CLK_HDMI_APB>,
+< IMX8MP_CLK_HDMI_REF_266M>,
+< IMX8MP_CLK_32K>,
+<_tx_phy>;
+ clock-names = "iahb", "isfr", "cec", "pix";
+ assigned-clocks = <
IMX8MP_CLK_HDMI_REF_266M>;
+ assigned-clock-parents = <
IMX8MP_SYS_PLL1_266M>;
+ power-domains = <_blk_ctrl
IMX8MP_HDMIBLK_PD_HDMI_TX>;
+ reg-io-width = <1>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ hd
[PATCH V8 10/12] drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI
From: Lucas Stach
Add a simple wrapper driver for the DWC HDMI bridge driver that
implements the few bits that are necessary to abstract the i.MX8MP
SoC integration.
Signed-off-by: Lucas Stach
Reviewed-by: Laurent Pinchart
Tested-by: Marek Vasut
Tested-by: Adam Ford #imx8mp-beacon
Tested-by: Richard Leitner
Tested-by: Frieder Schrempf
Tested-by: Luca Ceresoli
Signed-off-by: Adam Ford
---
v3: To move this along, I (Adam) took Lucas' V2 and attempted
to address concerns:
Changed name to imx8mp-hdmi-tx
Re-ordered includes to make drm come after linux
Removed unused variable build warning
Removed fdcc clock since it's part of the power domain now
set the phy_force_vendor = true
Removed comma after sentinel
Also added suspend/resume functions from Marek Vasut
Configured Kconfig to select the PVI and PHY automatically
since the HDMI-tx is useless without the other two components
I apologize that don't have the version history prior to V2.
---
drivers/gpu/drm/bridge/imx/Kconfig | 11 ++
drivers/gpu/drm/bridge/imx/Makefile | 1 +
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 154
3 files changed, 166 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index a4d13331e320..5965e8027529 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -3,6 +3,17 @@ if ARCH_MXC || COMPILE_TEST
config DRM_IMX_LDB_HELPER
tristate
+config DRM_IMX8MP_DW_HDMI_BRIDGE
+ tristate "Freescale i.MX8MP HDMI-TX bridge support"
+ depends on OF
+ depends on COMMON_CLK
+ select DRM_DW_HDMI
+ select DRM_IMX8MP_HDMI_PVI
+ select PHY_FSL_SAMSUNG_HDMI_PHY
+ help
+ Choose this to enable support for the internal HDMI encoder found
+ on the i.MX8MP SoC.
+
config DRM_IMX8MP_HDMI_PVI
tristate "Freescale i.MX8MP HDMI PVI bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
index e2c2106509fa..edb0a7b71b30 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
+obj-$(CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE) += imx8mp-hdmi-tx.o
obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
new file mode 100644
index ..89fc432ac611
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright (C) 2022 Pengutronix, Lucas Stach
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct imx8mp_hdmi {
+ struct dw_hdmi_plat_data plat_data;
+ struct dw_hdmi *dw_hdmi;
+ struct clk *pixclk;
+};
+
+static enum drm_mode_status
+imx8mp_hdmi_mode_valid(struct dw_hdmi *dw_hdmi, void *data,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ struct imx8mp_hdmi *hdmi = (struct imx8mp_hdmi *)data;
+
+ if (mode->clock < 13500)
+ return MODE_CLOCK_LOW;
+
+ if (mode->clock > 297000)
+ return MODE_CLOCK_HIGH;
+
+ if (clk_round_rate(hdmi->pixclk, mode->clock * 1000) !=
+ mode->clock * 1000)
+ return MODE_CLOCK_RANGE;
+
+ /* We don't support double-clocked and Interlaced modes */
+ if ((mode->flags & DRM_MODE_FLAG_DBLCLK) ||
+ (mode->flags & DRM_MODE_FLAG_INTERLACE))
+ return MODE_BAD;
+
+ return MODE_OK;
+}
+
+static int imx8mp_hdmi_phy_init(struct dw_hdmi *dw_hdmi, void *data,
+ const struct drm_display_info *display,
+ const struct drm_display_mode *mode)
+{
+ return 0;
+}
+
+static void imx8mp_hdmi_phy_disable(struct dw_hdmi *dw_hdmi, void *data)
+{
+}
+
+static void im8mp_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
+{
+ /*
+* Just release PHY core from reset, all other power management is done
+* by the PHY driver.
+*/
+ dw_hdmi_phy_gen1_reset(hdmi);
+
+ dw_hdmi_phy_setup_hpd(hdmi, data);
+}
+
+static const struct dw_hdmi_phy_ops imx8mp_hdmi_phy_ops = {
+ .init = imx8mp_hdmi_phy_init,
+ .disable= imx8mp_hdmi_phy_disable,
+ .setup_hpd = im8mp_hdmi_phy_setup_hpd,
+ .read_hpd = dw_hdmi_phy_read_hpd,
+ .update_hpd = dw_hdmi_phy_update_hpd,
+};
+
+static int imx8mp_dw_hdmi_probe(struct platform_device *pdev)
+{
+ struct device *
[PATCH V8 09/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
From: Lucas Stach
The HDMI TX controller on the i.MX8MP SoC is a Synopsys designware IP
core with a little bit of SoC integration around it.
Signed-off-by: Lucas Stach
Signed-off-by: Adam Ford
---
V3: Change name and location to better idenfity as a bridge and
HDMI 2.0a transmitter
Fix typos and feedback from Rob and added ports.
---
.../display/bridge/fsl,imx8mp-hdmi-tx.yaml| 102 ++
1 file changed, 102 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
new file mode 100644
index ..3791c9f4ebab
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8mp-hdmi-tx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP DWC HDMI TX Encoder
+
+maintainers:
+ - Lucas Stach
+
+description:
+ The i.MX8MP HDMI transmitter is a Synopsys DesignWare
+ HDMI 2.0a TX controller IP.
+
+allOf:
+ - $ref: /schemas/display/bridge/synopsys,dw-hdmi.yaml#
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8mp-hdmi-tx
+
+ reg-io-width:
+const: 1
+
+ clocks:
+maxItems: 4
+
+ clock-names:
+items:
+ - const: iahb
+ - const: isfr
+ - const: cec
+ - const: pix
+
+ power-domains:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Parallel RGB input port
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: HDMI output port
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - power-domains
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+hdmi@32fd8000 {
+compatible = "fsl,imx8mp-hdmi-tx";
+reg = <0x32fd8000 0x7eff>;
+interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+clocks = < IMX8MP_CLK_HDMI_APB>,
+ < IMX8MP_CLK_HDMI_REF_266M>,
+ < IMX8MP_CLK_32K>,
+ <_tx_phy>;
+clock-names = "iahb", "isfr", "cec", "pix";
+power-domains = <_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX>;
+reg-io-width = <1>;
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+
+ hdmi_tx_from_pvi: endpoint {
+ remote-endpoint = <_to_hdmi_tx>;
+ };
+ };
+
+ port@1 {
+reg = <1>;
+ hdmi_tx_out: endpoint {
+remote-endpoint = <_con>;
+ };
+ };
+};
+};
--
2.43.0
[PATCH V8 08/12] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
From: Lucas Stach
This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
full timing generator and can switch between different video sources. On
the i.MX8MP however the only supported source is the LCDIF. The block
just needs to be powered up and told about the polarity of the video
sync signals to act in bypass mode.
Signed-off-by: Lucas Stach
Reviewed-by: Luca Ceresoli (v7)
Tested-by: Marek Vasut (v1)
Tested-by: Luca Ceresoli (v7)
Tested-by: Richard Leitner (v2)
Tested-by: Frieder Schrempf (v2)
Reviewed-by: Laurent Pinchart (v3)
Reviewed-by: Luca Ceresoli
Tested-by: Luca Ceresoli
Tested-by: Fabio Estevam
Signed-off-by: Adam Ford
---
V8: No Change
V7: Re-do some includes to address build issues after rebasing from
Linux-next
V6: No change.
V5: I (Adam) tried to help move this along, so I took Lucas' patch and
attempted to apply fixes based on feedback. I don't have
all the history, so apologies for that.
No changes from V4 to V5
---
drivers/gpu/drm/bridge/imx/Kconfig | 7 +
drivers/gpu/drm/bridge/imx/Makefile | 1 +
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 207 +++
3 files changed, 215 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index 5a4f3d58501e..a4d13331e320 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -3,6 +3,13 @@ if ARCH_MXC || COMPILE_TEST
config DRM_IMX_LDB_HELPER
tristate
+config DRM_IMX8MP_HDMI_PVI
+ tristate "Freescale i.MX8MP HDMI PVI bridge support"
+ depends on OF
+ help
+ Choose this to enable support for the internal HDMI TX Parallel
+ Video Interface found on the Freescale i.MX8MP SoC.
+
config DRM_IMX8QM_LDB
tristate "Freescale i.MX8QM LVDS display bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
index 2b0c2e44aa1b..e2c2106509fa 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
+obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
new file mode 100644
index ..a76b7669fe8a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright (C) 2022 Pengutronix, Lucas Stach
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HTX_PVI_CTRL 0x0
+#define PVI_CTRL_OP_VSYNC_POL BIT(18)
+#define PVI_CTRL_OP_HSYNC_POL BIT(17)
+#define PVI_CTRL_OP_DE_POLBIT(16)
+#define PVI_CTRL_INP_VSYNC_POLBIT(14)
+#define PVI_CTRL_INP_HSYNC_POLBIT(13)
+#define PVI_CTRL_INP_DE_POL BIT(12)
+#define PVI_CTRL_MODE_MASKGENMASK(2, 1)
+#define PVI_CTRL_MODE_LCDIF 2
+#define PVI_CTRL_EN BIT(0)
+
+struct imx8mp_hdmi_pvi {
+ struct drm_bridge bridge;
+ struct device *dev;
+ struct drm_bridge *next_bridge;
+ void __iomem*regs;
+};
+
+static inline struct imx8mp_hdmi_pvi *
+to_imx8mp_hdmi_pvi(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct imx8mp_hdmi_pvi, bridge);
+}
+
+static int imx8mp_hdmi_pvi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+ struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+
+ return drm_bridge_attach(bridge->encoder, pvi->next_bridge,
+bridge, flags);
+}
+
+static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state)
+{
+ struct drm_atomic_state *state = bridge_state->base.state;
+ struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+ struct drm_connector_state *conn_state;
+ const struct drm_display_mode *mode;
+ struct drm_crtc_state *crtc_state;
+ struct drm_connector *connector;
+ u32 bus_flags, val;
+
+ connector = drm_atomic_get_new_connector_for_encoder(state,
bridge->encoder);
+ conn_state = drm_atomic_get_new_connector_state(state, connector);
+ crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+
+ if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
+ return;
+
+ mode = _state->
[PATCH V8 07/12] dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
From: Lucas Stach
Add binding for the i.MX8MP HDMI parallel video interface block.
Signed-off-by: Lucas Stach
Reviewed-by: Laurent Pinchart
Reviewed-by: Conor Dooley
Signed-off-by: Adam Ford
---
V8: Add interrupt-parent
V7: No Change
V6: Add s-o-b message for myself (Adam)
V5: I tried to help move this along, so I took Lucas' patch and
attempted to apply fixes based on feedback. I don't have
all the history, so apologies for that.
Removed the pipe character from the Description.
Increased the register size from 0x40 to 0x44.
---
.../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 84 +++
1 file changed, 84 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
diff --git
a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
new file mode 100644
index ..56da1636014c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pvi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP HDMI Parallel Video Interface
+
+maintainers:
+ - Lucas Stach
+
+description:
+ The HDMI parallel video interface is a timing and sync generator block in the
+ i.MX8MP SoC, that sits between the video source and the HDMI TX controller.
+
+properties:
+ compatible:
+const: fsl,imx8mp-hdmi-pvi
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input from the LCDIF controller.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output to the HDMI TX controller.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - power-domains
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display-bridge@32fc4000 {
+compatible = "fsl,imx8mp-hdmi-pvi";
+reg = <0x32fc4000 0x44>;
+interrupt-parent = <_hdmi>;
+interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+power-domains = <_blk_ctrl IMX8MP_HDMIBLK_PD_PVI>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+pvi_from_lcdif3: endpoint {
+remote-endpoint = <_to_pvi>;
+};
+};
+
+port@1 {
+reg = <1>;
+pvi_to_hdmi_tx: endpoint {
+remote-endpoint = <_tx_from_pvi>;
+};
+};
+};
+};
--
2.43.0
[PATCH V8 05/12] arm64: dts: imx8mp: add HDMI power-domains
From: Lucas Stach
This adds the PGC and HDMI blk-ctrl nodes providing power control for
HDMI subsystem peripherals.
Signed-off-by: Adam Ford
Signed-off-by: Lucas Stach
---
V2: Add missing power-domains hdcp and hrv
---
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 38 +++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 76c73daf546b..5c54073de615 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -836,6 +836,23 @@ pgc_mediamix: power-domain@10 {
<
IMX8MP_CLK_MEDIA_APB_ROOT>;
};
+ pgc_hdmimix: power-domains@14 {
+ #power-domain-cells = <0>;
+ reg =
;
+ clocks = <
IMX8MP_CLK_HDMI_ROOT>,
+<
IMX8MP_CLK_HDMI_APB>;
+ assigned-clocks = <
IMX8MP_CLK_HDMI_AXI>,
+ <
IMX8MP_CLK_HDMI_APB>;
+ assigned-clock-parents = <
IMX8MP_SYS_PLL2_500M>,
+<
IMX8MP_SYS_PLL1_133M>;
+ assigned-clock-rates =
<5>, <13300>;
+ };
+
+ pgc_hdmi_phy: power-domains@15 {
+ #power-domain-cells = <0>;
+ reg =
;
+ };
+
pgc_mipi_phy2: power-domain@16 {
#power-domain-cells = <0>;
reg =
;
@@ -1361,6 +1378,27 @@ eqos: ethernet@30bf {
intf_mode = < 0x4>;
status = "disabled";
};
+
+ hdmi_blk_ctrl: blk-ctrl@32fc {
+ compatible = "fsl,imx8mp-hdmi-blk-ctrl",
"syscon";
+ reg = <0x32fc 0x23c>;
+ clocks = < IMX8MP_CLK_HDMI_APB>,
+< IMX8MP_CLK_HDMI_ROOT>,
+< IMX8MP_CLK_HDMI_REF_266M>,
+< IMX8MP_CLK_HDMI_24M>,
+< IMX8MP_CLK_HDMI_FDCC_TST>;
+ clock-names = "apb", "axi", "ref_266m",
"ref_24m", "fdcc";
+ power-domains = <_hdmimix>, <_hdmimix>,
+ <_hdmimix>, <_hdmimix>,
+ <_hdmimix>, <_hdmimix>,
+ <_hdmimix>, <_hdmi_phy>,
+ <_hdmimix>, <_hdmimix>;
+ power-domain-names = "bus", "irqsteer", "lcdif",
+"pai", "pvi", "trng",
+"hdmi-tx", "hdmi-tx-phy",
+"hdcp", "hrv";
+ #power-domain-cells = <1>;
+ };
};
aips5: bus@30c0 {
--
2.43.0
[PATCH V8 06/12] arm64: dts: imx8mp: add HDMI irqsteer
From: Lucas Stach
The HDMI irqsteer is a secondary interrupt controller within the HDMI
subsystem that maps all HDMI peripheral IRQs into a single upstream
IRQ line.
Signed-off-by: Lucas Stach
---
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 5c54073de615..5e51a766f3d9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -1399,6 +1399,19 @@ hdmi_blk_ctrl: blk-ctrl@32fc {
"hdcp", "hrv";
#power-domain-cells = <1>;
};
+
+ irqsteer_hdmi: interrupt-controller@32fc2000 {
+ compatible = "fsl,imx-irqsteer";
+ reg = <0x32fc2000 0x44>;
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ fsl,channel = <1>;
+ fsl,num-irqs = <64>;
+ clocks = < IMX8MP_CLK_HDMI_APB>;
+ clock-names = "ipg";
+ power-domains = <_blk_ctrl
IMX8MP_HDMIBLK_PD_IRQSTEER>;
+ };
};
aips5: bus@30c0 {
--
2.43.0
[PATCH V8 04/12] pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix domain
According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of
hdmi rx verification IP that should not enable for HDMI TX.
But actually if the clock is disabled before HDMI/LCDIF probe,
LCDIF will not get pixel clock from HDMI PHY and print the error
logs:
[CRTC:39:crtc-2] vblank wait timed out
WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634
drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260
Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue.
Signed-off-by: Adam Ford
Reviewed-by: Jacky Bai
Signed-off-by: Sandor Yu
---
V2: No Change
---
drivers/pmdomain/imx/imx8mp-blk-ctrl.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
index e488cf79b800..77e889165eed 100644
--- a/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
+++ b/drivers/pmdomain/imx/imx8mp-blk-ctrl.c
@@ -55,7 +55,7 @@ struct imx8mp_blk_ctrl_domain_data {
const char *gpc_name;
};
-#define DOMAIN_MAX_CLKS 2
+#define DOMAIN_MAX_CLKS 3
#define DOMAIN_MAX_PATHS 3
struct imx8mp_blk_ctrl_domain {
@@ -457,8 +457,8 @@ static const struct imx8mp_blk_ctrl_domain_data
imx8mp_hdmi_domain_data[] = {
},
[IMX8MP_HDMIBLK_PD_LCDIF] = {
.name = "hdmiblk-lcdif",
- .clk_names = (const char *[]){ "axi", "apb" },
- .num_clks = 2,
+ .clk_names = (const char *[]){ "axi", "apb", "fdcc" },
+ .num_clks = 3,
.gpc_name = "lcdif",
.path_names = (const char *[]){"lcdif-hdmi"},
.num_paths = 1,
@@ -483,8 +483,8 @@ static const struct imx8mp_blk_ctrl_domain_data
imx8mp_hdmi_domain_data[] = {
},
[IMX8MP_HDMIBLK_PD_HDMI_TX] = {
.name = "hdmiblk-hdmi-tx",
- .clk_names = (const char *[]){ "apb", "ref_266m" },
- .num_clks = 2,
+ .clk_names = (const char *[]){ "apb", "ref_266m", "fdcc" },
+ .num_clks = 3,
.gpc_name = "hdmi-tx",
},
[IMX8MP_HDMIBLK_PD_HDMI_TX_PHY] = {
--
2.43.0
[PATCH V8 03/12] dt-bindings: soc: imx: add missing clock and power-domains to imx8mp-hdmi-blk-ctrl
Per guidance from the NXP downstream kernel, if the clock is disabled before HDMI/LCDIF probe, LCDIF will not get pixel clock from HDMI PHY and throw an error: [CRTC:39:crtc-2] vblank wait timed out WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c: 1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 Fix this by adding the fdcc clock to the hdmi_blk_ctrl. This should be safe, since neither this power domain nor the dependent HDMI and LCDIF drivers been enabled or added to the SoC device tree yet. According to Sandor Yu from NXP, "the FDCC clock is not for HDMITX in desgin, but it is part of HDMI domain that needed by HDMITX. So I think it is reasonable added it to the power domain driver." The driver also supports two power domains which are missing from the binding that also fix an issue with resuming from suspend. Signed-off-by: Adam Ford --- V2: Update commit message to both show error and give a bit more background. Add missing power domains hdcp and hdrv as pointed out by Marek Vasut --- .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml | 22 --- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml index 1be4ce2a45e8..bd1cdaa4f54b 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml @@ -27,8 +27,8 @@ properties: const: 1 power-domains: -minItems: 8 -maxItems: 8 +minItems: 10 +maxItems: 10 power-domain-names: items: @@ -40,10 +40,12 @@ properties: - const: trng - const: hdmi-tx - const: hdmi-tx-phy + - const: hdcp + - const: hrv clocks: -minItems: 4 -maxItems: 4 +minItems: 5 +maxItems: 5 clock-names: items: @@ -51,6 +53,7 @@ properties: - const: axi - const: ref_266m - const: ref_24m + - const: fdcc interconnects: maxItems: 3 @@ -82,12 +85,15 @@ examples: clocks = < IMX8MP_CLK_HDMI_APB>, < IMX8MP_CLK_HDMI_ROOT>, < IMX8MP_CLK_HDMI_REF_266M>, - < IMX8MP_CLK_HDMI_24M>; -clock-names = "apb", "axi", "ref_266m", "ref_24m"; + < IMX8MP_CLK_HDMI_24M>, + < IMX8MP_CLK_HDMI_FDCC_TST>; +clock-names = "apb", "axi", "ref_266m", "ref_24m", "fdcc"; power-domains = <_hdmimix>, <_hdmimix>, <_hdmimix>, <_hdmimix>, <_hdmimix>, <_hdmimix>, -<_hdmimix>, <_hdmi_phy>; +<_hdmimix>, <_hdmi_phy>, +<_hdmimix>, <_hdmimix>; power-domain-names = "bus", "irqsteer", "lcdif", "pai", "pvi", "trng", - "hdmi-tx", "hdmi-tx-phy"; + "hdmi-tx", "hdmi-tx-phy", + "hdcp", "hrv"; #power-domain-cells = <1>; }; -- 2.43.0
[PATCH V8 01/12] dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
From: Lucas Stach
Add a DT binding for the HDMI PHY found on the i.MX8MP SoC.
Signed-off-by: Lucas Stach
Signed-off-by: Adam Ford
Reviewed-by: Krzysztof Kozlowski
---
V3: Removed mintems at the request of Krzysztof and add his
reviewed-by
V2: I tried to help move this along, so I took Lucas' patch and
attempted to apply fixes based on feedback. I don't have
all the history, so apologies for that.
Added phy-cells to the required list and fixed an error due
to the word 'binding' being in the title.
---
.../bindings/phy/fsl,imx8mp-hdmi-phy.yaml | 62 +++
1 file changed, 62 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
b/Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
new file mode 100644
index ..c43e86a8c2e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,imx8mp-hdmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP HDMI PHY
+
+maintainers:
+ - Lucas Stach
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8mp-hdmi-phy
+
+ reg:
+maxItems: 1
+
+ "#clock-cells":
+const: 0
+
+ clocks:
+maxItems: 2
+
+ clock-names:
+items:
+ - const: apb
+ - const: ref
+
+ "#phy-cells":
+const: 0
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - clocks
+ - clock-names
+ - "#phy-cells"
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+phy@32fdff00 {
+compatible = "fsl,imx8mp-hdmi-phy";
+reg = <0x32fdff00 0x100>;
+clocks = < IMX8MP_CLK_HDMI_APB>,
+ < IMX8MP_CLK_HDMI_24M>;
+clock-names = "apb", "ref";
+power-domains = <_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX_PHY>;
+#clock-cells = <0>;
+#phy-cells = <0>;
+};
--
2.43.0
[PATCH V8 02/12] phy: freescale: add Samsung HDMI PHY
From: Lucas Stach
This adds the driver for the Samsung HDMI PHY found on the
i.MX8MP SoC.
Signed-off-by: Lucas Stach
Signed-off-by: Adam Ford
Tested-by: Alexander Stein
---
V4: Make lookup table hex values lower case.
V3: Re-order the Makefile to keep it alphabetical
Remove unused defines
V2: Fixed some whitespace found from checkpatch
Change error handling when enabling apbclk to use dev_err_probe
Rebase on Linux-Next
I (Adam) tried to help move this along, so I took Lucas' patch and
attempted to apply fixes based on feedback. I don't have
all the history, so apologies for that.
---
drivers/phy/freescale/Kconfig|6 +
drivers/phy/freescale/Makefile |1 +
drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 ++
3 files changed, 1082 insertions(+)
create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index 853958fb2c06..5c2b73042dfc 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -35,6 +35,12 @@ config PHY_FSL_IMX8M_PCIE
Enable this to add support for the PCIE PHY as found on
i.MX8M family of SOCs.
+config PHY_FSL_SAMSUNG_HDMI_PHY
+ tristate "Samsung HDMI PHY support"
+ depends on OF && HAS_IOMEM
+ help
+ Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
+
endif
config PHY_FSL_LYNX_28G
diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
index cedb328bc4d2..79e5f16d3ce8 100644
--- a/drivers/phy/freescale/Makefile
+++ b/drivers/phy/freescale/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_PHY_MIXEL_LVDS_PHY)+=
phy-fsl-imx8qm-lvds-phy.o
obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += phy-fsl-imx8-mipi-dphy.o
obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o
obj-$(CONFIG_PHY_FSL_LYNX_28G) += phy-fsl-lynx-28g.o
+obj-$(CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY) += phy-fsl-samsung-hdmi.o
diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
new file mode 100644
index ..bf0e2299d00f
--- /dev/null
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -0,0 +1,1075 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 NXP
+ * Copyright 2022 Pengutronix, Lucas Stach
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PHY_REG_33 0x84
+#define REG33_MODE_SET_DONE BIT(7)
+#define REG33_FIX_DA BIT(1)
+
+#define PHY_REG_34 0x88
+#define REG34_PHY_READY BIT(7)
+#define REG34_PLL_LOCKBIT(6)
+#define REG34_PHY_CLK_READY BIT(5)
+
+
+#define PHY_PLL_REGS_NUM 48
+
+struct phy_config {
+ u32 clk_rate;
+ u8 regs[PHY_PLL_REGS_NUM];
+};
+
+const struct phy_config phy_pll_cfg[] = {
+ { 2225, {
+ 0x00, 0xd1, 0x4b, 0xf1, 0x89, 0x88, 0x80, 0x40,
+ 0x4f, 0x30, 0x33, 0x65, 0x00, 0x15, 0x25, 0x80,
+ 0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+ 0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+ 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+ },
+ }, {
+ 2375, {
+ 0x00, 0xd1, 0x50, 0xf1, 0x86, 0x85, 0x80, 0x40,
+ 0x4f, 0x30, 0x33, 0x65, 0x00, 0x03, 0x25, 0x80,
+ 0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+ 0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+ 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+ },
+ }, {
+ 2400, {
+ 0x00, 0xd1, 0x50, 0xf0, 0x00, 0x00, 0x80, 0x00,
+ 0x4f, 0x30, 0x33, 0x65, 0x00, 0x01, 0x25, 0x80,
+ 0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+ 0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+ 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+ },
+ }, {
+ 24024000, {
+ 0x00, 0xd1, 0x50, 0xf1, 0x99, 0x02, 0x80, 0x40,
+ 0x4f, 0x30, 0x33, 0x65, 0x00, 0x00, 0x25, 0x80,
+ 0x6c, 0xf2, 0x67, 0x00, 0x10, 0x8f, 0x30, 0x32,
+ 0x60, 0x8f, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+ 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0xe0, 0x83, 0x0f, 0x3e, 0xf8, 0x00, 0x00,
+ },
+ }, {
+ 25175000, {
+ 0x00, 0xd1, 0x54
[PATCH V8 00/12] soc: imx8mp: Add support for HDMI
The i.MX8M Plus has an HDMI controller, but it depends on two other systems, the Parallel Video Interface (PVI) and the HDMI PHY from Samsung. The LCDIF controller generates the display and routes it to the PVI which converts passes the parallel video to the HDMI bridge. The HDMI system has a corresponding power domain controller whose driver was partially written, but the device tree for it was never applied, so some changes to the power domain should be harmless because they've not really been used yet. This series is adapted from multiple series from Lucas Stach with edits and suggestions from feedback from various series, but it since it's difficult to use and test them independently, I merged them into on unified series. The version history is a bit ambiguous since different components were submitted at different times and had different amount of retries. In an effort to merge them I used the highest version attempt. Adam Ford (3): dt-bindings: soc: imx: add missing clock and power-domains to imx8mp-hdmi-blk-ctrl pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix domain arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module Lucas Stach (9): dt-bindings: phy: add binding for the i.MX8MP HDMI PHY phy: freescale: add Samsung HDMI PHY arm64: dts: imx8mp: add HDMI power-domains arm64: dts: imx8mp: add HDMI irqsteer dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI drm/bridge: imx: add driver for HDMI TX Parallel Video Interface dt-bindings: display: imx: add binding for i.MX8MP HDMI TX drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI arm64: dts: imx8mp: add HDMI display pipeline .../display/bridge/fsl,imx8mp-hdmi-tx.yaml| 102 ++ .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 84 ++ .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml | 62 + .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml | 22 +- arch/arm64/boot/dts/freescale/imx8mp.dtsi | 145 +++ arch/arm64/configs/defconfig |1 + drivers/gpu/drm/bridge/imx/Kconfig| 18 + drivers/gpu/drm/bridge/imx/Makefile |2 + drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 207 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 154 +++ drivers/phy/freescale/Kconfig |6 + drivers/phy/freescale/Makefile|1 + drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 + drivers/pmdomain/imx/imx8mp-blk-ctrl.c| 10 +- 14 files changed, 1876 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c -- 2.43.0
Re: [PATCH V2 2/2] phy: freescale: add Samsung HDMI PHY
On Fri, Feb 2, 2024 at 5:20 AM Luca Ceresoli wrote: > > Hello Adam, > > On Sat, 6 Jan 2024 16:19:05 -0600 > Adam Ford wrote: > > > From: Lucas Stach > > > > This adds the driver for the Samsung HDMI PHY found on the > > i.MX8MP SoC. > > > > Signed-off-by: Lucas Stach > > Signed-off-by: Adam Ford > > I had already tested the v2 from Lucas, however I also tested this > version which works as well, on v6.8-rc1, custom hardware based on the > Avnet i.MX8MP SMARC SoM. > > Tested-by: Luca Ceresoli > Thanks for testing. > Generally speaking, as there are several small patch series around which > together implement HDMI on iMX8MP and similar, I think it would be much > easier fore reviewing and testing if they were grouped into a unique > series. That will happen for my next attempt to push this series. It was a headache for me to gather them all. I have a github repo setup with my latest edits here if you're interested: https://github.com/aford173/linux/tree/for-6.9-imx8mp-hdmi adam > > Luca > > -- > Luca Ceresoli, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
Re: [PATCH V2 2/2] phy: freescale: add Samsung HDMI PHY
On Tue, Jan 30, 2024 at 11:00 AM Vinod Koul wrote:
>
> Hi Adam,
>
> On 06-01-24, 16:19, Adam Ford wrote:
> > From: Lucas Stach
> >
> > This adds the driver for the Samsung HDMI PHY found on the
> > i.MX8MP SoC.
> >
> > Signed-off-by: Lucas Stach
> > Signed-off-by: Adam Ford
> > ---
> > V2: Fixed some whitespace found from checkpatch
> > Change error handling when enabling apbclk to use dev_err_probe
> > Rebase on Linux-Next
> >
> > I (Adam) tried to help move this along, so I took Lucas' patch and
> > attempted to apply fixes based on feedback. I don't have
> > all the history, so apologies for that.
> >
> > diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> > index 853958fb2c06..5c2b73042dfc 100644
> > --- a/drivers/phy/freescale/Kconfig
> > +++ b/drivers/phy/freescale/Kconfig
> > @@ -35,6 +35,12 @@ config PHY_FSL_IMX8M_PCIE
> > Enable this to add support for the PCIE PHY as found on
> > i.MX8M family of SOCs.
> >
> > +config PHY_FSL_SAMSUNG_HDMI_PHY
> > + tristate "Samsung HDMI PHY support"
> > + depends on OF && HAS_IOMEM
> > + help
> > + Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
> > +
> > endif
> >
> > config PHY_FSL_LYNX_28G
> > diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> > index cedb328bc4d2..dbcafdcc8751 100644
> > --- a/drivers/phy/freescale/Makefile
> > +++ b/drivers/phy/freescale/Makefile
> > @@ -3,4 +3,5 @@ obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) +=
> > phy-fsl-imx8mq-usb.o
> > obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += phy-fsl-imx8qm-lvds-phy.o
> > obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-fsl-imx8-mipi-dphy.o
> > obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o
> > +obj-$(CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY) += phy-fsl-samsung-hdmi.o
> > obj-$(CONFIG_PHY_FSL_LYNX_28G) += phy-fsl-lynx-28g.o
> > diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > new file mode 100644
> > index ..54e93ea898f7
> > --- /dev/null
> > +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > @@ -0,0 +1,1078 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2020 NXP
> > + * Copyright 2022 Pengutronix, Lucas Stach
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define HDMI_TX_CONTROL0 0x200
> > +#define HDMI_TX_CONTROL_PHY_PWRDWN BIT(3)
> > +
> > +#define PHY_REG_33 0x84
> > +#define REG33_MODE_SET_DONE BIT(7)
> > +#define REG33_FIX_DABIT(1)
> > +
> > +#define PHY_REG_34 0x88
> > +#define REG34_PHY_READY BIT(7)
> > +#define REG34_PLL_LOCK BIT(6)
> > +#define REG34_PHY_CLK_READY BIT(5)
> > +
> > +
> > +#define PHY_PLL_REGS_NUM 48
> > +
> > +struct phy_config {
> > + u32 clk_rate;
> > + u8 regs[PHY_PLL_REGS_NUM];
> > +};
> > +
> > +const struct phy_config phy_pll_cfg[] = {
> > + { 2225, {
> > + 0x00, 0xD1, 0x4B, 0xF1, 0x89, 0x88, 0x80, 0x40,
> > + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x15, 0x25, 0x80,
> > + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
> > + 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> > + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > + 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
>
> can we please have lower case hex values
I'll update that for the next revision.
>
> > + },
> > + }, {
> > + 2375, {
> > + 0x00, 0xD1, 0x50, 0xF1, 0x86, 0x85, 0x80, 0x40,
> > + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x03, 0x25, 0x80,
> > + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
> > + 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> > + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > + 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
> > + },
> > + }, {
> > + 2400, {
> > + 0x00, 0xD1, 0x50, 0xF0, 0x00, 0x00, 0x80, 0x00,
&
Re: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
On Mon, Dec 18, 2023 at 2:59 AM Alexander Stein wrote: > > Hi everybody, > > Am Montag, 18. Dezember 2023, 09:48:49 CET schrieb Luca Ceresoli: > > Hi, > > > > On Mon, 18 Dec 2023 04:36:55 +0200 > > > > Laurent Pinchart wrote: > > > On Fri, Dec 15, 2023 at 05:09:41PM -0300, Fabio Estevam wrote: > > > > On Fri, Dec 15, 2023 at 4:01 PM Adam Ford wrote: > > > > > Thanks for the list. I was able to successfully build the stable 6.6 > > > > > branch with those patches applied and I have the HDMI working. > > > > > Unfortunately, I get build errors on the linux-next, so it's going to > > > > > take me a little time to sort through all of this. > > > > > > > > If you need help to figure this problem out, please let me know. > > > > > > > > I haven't tried it against linux-next. > > > > > > > > > I am thinking that it would be better to consolidate all these > > > > > together into one series instead of piecemealing it. However, there > > > > > are some items that can be submitted right away without significantly > > > > > reworking them against linux-next. Do people have a preference? > > > > > > > > I think it makes sense to re-submit the "easy ones" right away. > > > > > > Agreed. The more we can merge quickly, the easier it will become to > > > rebase and upstream the rest. > > > > I agree as well, "release early, release often". These patches are > > around since a long time and lots of people are using them already, and > > tracking all of them from different threads is time-consuming. I will > > happily test them early as soon as they are sent. > > I lost track of the series well, but I do remember I had to adjust the > original series to get it running on linux-next. > Please keep me on CC so I can add my local changes if necessary. Fabio / Alexander, I have a pending question to Peng regarding a change I pulled from NXP [1] which moves the FDCC clock to the power domain and removes it from the HDMI-TX driver. I am hoping to get that answered soon. If not, I might just push the series again after a few more days. In the meantime, I have a git repo [2] if anyone wants to review stuff. Marek Vasut sent me an offline patch to address some suspend/resume issues, and I incorporated them into the series. My suspend-resume has been broken for a while, so I cannot test that. > I have a proof of concept for HDMI audio, which is based on the base HDMI > support. I can continue on that after merge, but I'm lacking an idea how to > add some kind of "bridge" into the audio pipeline. Maybe the git repo above will help. It looks like the xcvr and audio-tx drivers are there, but they appear to be dependent on custom NXP sound card drivers which would be nice to replace with standard audio drivers, so let me know if I can assist in any way. > > Best regards > Alexander > -- > TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany > Amtsgericht München, HRB 105018 > Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider > http://www.tq-group.com/ > [1] - https://patchwork.kernel.org/project/linux-pm/patch/20240106223951.387067-2-aford...@gmail.com/ [2] - https://github.com/aford173/linux/tree/for-6.9-imx8mp-hdmi >
Re: [PATCH V2 2/2] phy: freescale: add Samsung HDMI PHY
On Mon, Jan 8, 2024 at 9:03 AM Alexander Stein
wrote:
>
> Hi Adam,
>
> thanks for pushing this forward.
>
> Am Samstag, 6. Januar 2024, 23:19:05 CET schrieb Adam Ford:
> > From: Lucas Stach
> >
> > This adds the driver for the Samsung HDMI PHY found on the
> > i.MX8MP SoC.
> >
> > Signed-off-by: Lucas Stach
> > Signed-off-by: Adam Ford
> > ---
> > V2: Fixed some whitespace found from checkpatch
> > Change error handling when enabling apbclk to use dev_err_probe
> > Rebase on Linux-Next
> >
> > I (Adam) tried to help move this along, so I took Lucas' patch and
> > attempted to apply fixes based on feedback. I don't have
> > all the history, so apologies for that.
> >
> > diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> > index 853958fb2c06..5c2b73042dfc 100644
> > --- a/drivers/phy/freescale/Kconfig
> > +++ b/drivers/phy/freescale/Kconfig
> > @@ -35,6 +35,12 @@ config PHY_FSL_IMX8M_PCIE
> > Enable this to add support for the PCIE PHY as found on
> > i.MX8M family of SOCs.
> >
> > +config PHY_FSL_SAMSUNG_HDMI_PHY
> > + tristate "Samsung HDMI PHY support"
> > + depends on OF && HAS_IOMEM
> > + help
> > + Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
> > +
> > endif
> >
> > config PHY_FSL_LYNX_28G
> > diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> > index cedb328bc4d2..dbcafdcc8751 100644
> > --- a/drivers/phy/freescale/Makefile
> > +++ b/drivers/phy/freescale/Makefile
> > @@ -3,4 +3,5 @@ obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) +=
> > phy-fsl-imx8mq-usb.o
> > obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += phy-fsl-imx8qm-lvds-phy.o
> > obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-fsl-imx8-mipi-dphy.o
> > obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o
> > +obj-$(CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY) += phy-fsl-samsung-hdmi.o
> > obj-$(CONFIG_PHY_FSL_LYNX_28G) += phy-fsl-lynx-28g.o
>
> I don't know if there was different feedback already. But I would have added
> the entry sorted alphabetically, thus after CONFIG_PHY_FSL_LYNX_28G. Same
> goes,
> for Kconfig as well.
The Makefile is easy to rearrange, but Kconfig is already out of
alphabetical order, and PHY_FSL_SAMSUNG_HDMI_PHY is encapsulated in an
if statement, so it cannot go after PHY_FSL_LYNX_28G. It is
alphabetical after PHY_FSL_IMX8M.
>
> > diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c new file mode 100644
> > index ..54e93ea898f7
> > --- /dev/null
> > +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> > @@ -0,0 +1,1078 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2020 NXP
> > + * Copyright 2022 Pengutronix, Lucas Stach
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define HDMI_TX_CONTROL0 0x200
> > +#define HDMI_TX_CONTROL_PHY_PWRDWN BIT(3)
>
> These defines are unused here.
I can drop these.
>
> > +
> > +#define PHY_REG_33 0x84
> > +#define REG33_MODE_SET_DONE BIT(7)
> > +#define REG33_FIX_DABIT(1)
> > +
> > +#define PHY_REG_34 0x88
> > +#define REG34_PHY_READY BIT(7)
> > +#define REG34_PLL_LOCK BIT(6)
> > +#define REG34_PHY_CLK_READY BIT(5)
> > +
> > +
> > +#define PHY_PLL_REGS_NUM 48
> > +
> > +struct phy_config {
> > + u32 clk_rate;
> > + u8 regs[PHY_PLL_REGS_NUM];
>
> Shouldn't reg be aligned along clk_rate?
Why so? They appear to just be structures where individual parts are
read/written individually. Looking at another HDMI phy driver, it's
not really any different.
>
> Despite that. Tested on TQMa8MPQL/MBa8MPxL + Full-HD HDMI monitor.
>
> Tested-by: Alexander Stein
>
Thanks for testing.
adam
> Best regards,
> Alexander
>
>
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> http://www.tq-group.com/
>
>
Re: [PATCH 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding
On Mon, Dec 11, 2023 at 9:33 PM Adam Ford wrote:
>
> When using video sync pulses, the HFP, HBP, and HSA are divided between
> the available lanes if there is more than one lane. For certain
> timings and lane configurations, the HFP may not be evenly divisible.
> If the HFP is rounded down, it ends up being too small which can cause
> some monitors to not sync properly. In these instances, adjust htotal
> and hsync to round the HFP up, and recalculate the htotal.
>
> Tested-by: Frieder Schrempf # Kontron BL
> i.MX8MM with HDMI monitor
> Signed-off-by: Adam Ford
Gentle nudge on this one. Basically this fixes an issue with the 8MP,
but it's still unknown why it doesn't work on 8MM or 8MN, but Frieder
confirmed there are no regressions on 8MM or 8MN.
adam
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 239d253a7d71..f5795da1d8bb 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1628,6 +1628,27 @@ static int samsung_dsim_atomic_check(struct drm_bridge
> *bridge,
> adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC);
> }
>
> + /*
> +* When using video sync pulses, the HFP, HBP, and HSA are divided
> between
> +* the available lanes if there is more than one lane. For certain
> +* timings and lane configurations, the HFP may not be evenly
> divisible.
> +* If the HFP is rounded down, it ends up being too small which can
> cause
> +* some monitors to not sync properly. In these instances, adjust
> htotal
> +* and hsync to round the HFP up, and recalculate the htotal. Through
> trial
> +* and error, it appears that the HBP and HSA do not appearto need
> the same
> +* correction that HFP does.
> +*/
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes >
> 1) {
> + int hfp = adjusted_mode->hsync_start -
> adjusted_mode->hdisplay;
> + int remainder = hfp % dsi->lanes;
> +
> + if (remainder) {
> + adjusted_mode->hsync_start += remainder;
> + adjusted_mode->hsync_end += remainder;
> + adjusted_mode->htotal += remainder;
> + }
> + }
> +
> return 0;
> }
>
> --
> 2.40.1
>
Re: [PATCH V7 1/2] dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
On Wed, Jan 10, 2024 at 5:48 AM Alexander Stein
wrote:
>
> Hi Adam,
>
> thanks for pushing this forward.
>
> Am Samstag, 6. Januar 2024, 22:51:44 CET schrieb Adam Ford:
> > From: Lucas Stach
> >
> > Add binding for the i.MX8MP HDMI parallel video interface block.
> >
> > Signed-off-by: Lucas Stach
> > Reviewed-by: Laurent Pinchart
> > Reviewed-by: Conor Dooley
> > Signed-off-by: Adam Ford
> > ---
> > V7: No Change
> >
> > V6: Add s-o-b message for myself (Adam)
> >
> > V5: I tried to help move this along, so I took Lucas' patch and
> > attempted to apply fixes based on feedback. I don't have
> > all the history, so apologies for that.
> > Removed the pipe character from the Description.
> > Increased the register size from 0x40 to 0x44.
> > diff --git
> > a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> > b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> > new file mode 100644
> > index ..3377f152f319
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> > @@ -0,0 +1,83 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pvi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Freescale i.MX8MP HDMI Parallel Video Interface
> > +
> > +maintainers:
> > + - Lucas Stach
> > +
> > +description:
> > + The HDMI parallel video interface is a timing and sync generator block in
> > the + i.MX8MP SoC, that sits between the video source and the HDMI TX
> > controller. +
> > +properties:
> > + compatible:
> > +const: fsl,imx8mp-hdmi-pvi
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > + power-domains:
> > +maxItems: 1
> > +
> > + ports:
> > +$ref: /schemas/graph.yaml#/properties/ports
> > +
> > +properties:
> > + port@0:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: Input from the LCDIF controller.
> > +
> > + port@1:
> > +$ref: /schemas/graph.yaml#/properties/port
> > +description: Output to the HDMI TX controller.
> > +
> > +required:
> > + - port@0
> > + - port@1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - power-domains
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +
> > +display-bridge@32fc4000 {
> > +compatible = "fsl,imx8mp-hdmi-pvi";
> > +reg = <0x32fc4000 0x44>;
>
> Shall interrupt-parent = <_hdmi>; be added here as well?
That does appear to the case. Good catch. The HDMI documentation
isn't as thorough as some other parts of the tech ref manual are.
I'll fix this when I resubmit
adam
>
> Best regards,
> Alexander
>
> > +interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
> > +power-domains = <_blk_ctrl IMX8MP_HDMIBLK_PD_PVI>;
> > +
> > +ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +port@0 {
> > +reg = <0>;
> > +pvi_from_lcdif3: endpoint {
> > +remote-endpoint = <_to_pvi>;
> > +};
> > +};
> > +
> > +port@1 {
> > +reg = <1>;
> > +pvi_to_hdmi_tx: endpoint {
> > +remote-endpoint = <_tx_from_pvi>;
> > +};
> > +};
> > +};
> > +};
>
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> http://www.tq-group.com/
>
>
[PATCH V2 2/2] phy: freescale: add Samsung HDMI PHY
From: Lucas Stach
This adds the driver for the Samsung HDMI PHY found on the
i.MX8MP SoC.
Signed-off-by: Lucas Stach
Signed-off-by: Adam Ford
---
V2: Fixed some whitespace found from checkpatch
Change error handling when enabling apbclk to use dev_err_probe
Rebase on Linux-Next
I (Adam) tried to help move this along, so I took Lucas' patch and
attempted to apply fixes based on feedback. I don't have
all the history, so apologies for that.
diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index 853958fb2c06..5c2b73042dfc 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -35,6 +35,12 @@ config PHY_FSL_IMX8M_PCIE
Enable this to add support for the PCIE PHY as found on
i.MX8M family of SOCs.
+config PHY_FSL_SAMSUNG_HDMI_PHY
+ tristate "Samsung HDMI PHY support"
+ depends on OF && HAS_IOMEM
+ help
+ Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
+
endif
config PHY_FSL_LYNX_28G
diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
index cedb328bc4d2..dbcafdcc8751 100644
--- a/drivers/phy/freescale/Makefile
+++ b/drivers/phy/freescale/Makefile
@@ -3,4 +3,5 @@ obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)+= phy-fsl-imx8mq-usb.o
obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += phy-fsl-imx8qm-lvds-phy.o
obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += phy-fsl-imx8-mipi-dphy.o
obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o
+obj-$(CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY) += phy-fsl-samsung-hdmi.o
obj-$(CONFIG_PHY_FSL_LYNX_28G) += phy-fsl-lynx-28g.o
diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
new file mode 100644
index ..54e93ea898f7
--- /dev/null
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -0,0 +1,1078 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 NXP
+ * Copyright 2022 Pengutronix, Lucas Stach
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HDMI_TX_CONTROL0 0x200
+#define HDMI_TX_CONTROL_PHY_PWRDWNBIT(3)
+
+#define PHY_REG_33 0x84
+#define REG33_MODE_SET_DONE BIT(7)
+#define REG33_FIX_DA BIT(1)
+
+#define PHY_REG_34 0x88
+#define REG34_PHY_READY BIT(7)
+#define REG34_PLL_LOCKBIT(6)
+#define REG34_PHY_CLK_READY BIT(5)
+
+
+#define PHY_PLL_REGS_NUM 48
+
+struct phy_config {
+ u32 clk_rate;
+ u8 regs[PHY_PLL_REGS_NUM];
+};
+
+const struct phy_config phy_pll_cfg[] = {
+ { 2225, {
+ 0x00, 0xD1, 0x4B, 0xF1, 0x89, 0x88, 0x80, 0x40,
+ 0x4F, 0x30, 0x33, 0x65, 0x00, 0x15, 0x25, 0x80,
+ 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
+ 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+ 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
+ },
+ }, {
+ 2375, {
+ 0x00, 0xD1, 0x50, 0xF1, 0x86, 0x85, 0x80, 0x40,
+ 0x4F, 0x30, 0x33, 0x65, 0x00, 0x03, 0x25, 0x80,
+ 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
+ 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+ 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
+ },
+ }, {
+ 2400, {
+ 0x00, 0xD1, 0x50, 0xF0, 0x00, 0x00, 0x80, 0x00,
+ 0x4F, 0x30, 0x33, 0x65, 0x00, 0x01, 0x25, 0x80,
+ 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
+ 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+ 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
+ },
+ }, {
+ 24024000, {
+ 0x00, 0xD1, 0x50, 0xF1, 0x99, 0x02, 0x80, 0x40,
+ 0x4F, 0x30, 0x33, 0x65, 0x00, 0x00, 0x25, 0x80,
+ 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
+ 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+ 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
+ },
+ }, {
+ 25175000, {
+ 0x00, 0xD1, 0x54, 0xFC, 0xCC, 0x91, 0x80, 0x40,
+ 0x4F, 0x30, 0x33, 0x65, 0x00, 0xF5, 0x24, 0x80,
+ 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
+ 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
+ 0x00, 0x80
[PATCH V2 1/2] dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
From: Lucas Stach
Add a DT binding for the HDMI PHY found on the i.MX8MP SoC.
Signed-off-by: Lucas Stach
Signed-off-by: Adam Ford
---
V2: Rebase on Linux-Next
Fix bot error due to the word 'binding' being in the description
Add phy-cells to the required list
diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
b/Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
new file mode 100644
index ..d1b941b48151
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,imx8mp-hdmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP HDMI PHY
+
+maintainers:
+ - Lucas Stach
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8mp-hdmi-phy
+
+ reg:
+maxItems: 1
+
+ "#clock-cells":
+const: 0
+
+ clocks:
+minItems: 2
+maxItems: 2
+
+ clock-names:
+items:
+ - const: apb
+ - const: ref
+
+ "#phy-cells":
+const: 0
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - clocks
+ - clock-names
+ - "#phy-cells"
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+phy@32fdff00 {
+compatible = "fsl,imx8mp-hdmi-phy";
+reg = <0x32fdff00 0x100>;
+clocks = < IMX8MP_CLK_HDMI_APB>,
+ < IMX8MP_CLK_HDMI_24M>;
+clock-names = "apb", "ref";
+power-domains = <_blk_ctrl IMX8MP_HDMIBLK_PD_HDMI_TX_PHY>;
+#clock-cells = <0>;
+#phy-cells = <0>;
+};
--
2.43.0
[PATCH V7 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
From: Lucas Stach
This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
full timing generator and can switch between different video sources. On
the i.MX8MP however the only supported source is the LCDIF. The block
just needs to be powered up and told about the polarity of the video
sync signals to act in bypass mode.
Signed-off-by: Lucas Stach
Reviewed-by: Luca Ceresoli (v2)
Tested-by: Marek Vasut (v1)
Tested-by: Luca Ceresoli (v2)
Tested-by: Richard Leitner (v2)
Tested-by: Frieder Schrempf (v2)
Reviewed-by: Laurent Pinchart (v3)
Reviewed-by: Luca Ceresoli
Tested-by: Luca Ceresoli
Tested-by: Fabio Estevam
Signed-off-by: Adam Ford
---
V7: Re-do some includes to address build issues after rebasing from
Linux-next
V6: No change.
V5: I (Adam) tried to help move this along, so I took Lucas' patch and
attempted to apply fixes based on feedback. I don't have
all the history, so apologies for that.
No changes from V4 to V5
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index 5a4f3d58501e..a4d13331e320 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -3,6 +3,13 @@ if ARCH_MXC || COMPILE_TEST
config DRM_IMX_LDB_HELPER
tristate
+config DRM_IMX8MP_HDMI_PVI
+ tristate "Freescale i.MX8MP HDMI PVI bridge support"
+ depends on OF
+ help
+ Choose this to enable support for the internal HDMI TX Parallel
+ Video Interface found on the Freescale i.MX8MP SoC.
+
config DRM_IMX8QM_LDB
tristate "Freescale i.MX8QM LVDS display bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
index 2b0c2e44aa1b..e2c2106509fa 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
+obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
new file mode 100644
index ..a76b7669fe8a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright (C) 2022 Pengutronix, Lucas Stach
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HTX_PVI_CTRL 0x0
+#define PVI_CTRL_OP_VSYNC_POL BIT(18)
+#define PVI_CTRL_OP_HSYNC_POL BIT(17)
+#define PVI_CTRL_OP_DE_POLBIT(16)
+#define PVI_CTRL_INP_VSYNC_POLBIT(14)
+#define PVI_CTRL_INP_HSYNC_POLBIT(13)
+#define PVI_CTRL_INP_DE_POL BIT(12)
+#define PVI_CTRL_MODE_MASKGENMASK(2, 1)
+#define PVI_CTRL_MODE_LCDIF 2
+#define PVI_CTRL_EN BIT(0)
+
+struct imx8mp_hdmi_pvi {
+ struct drm_bridge bridge;
+ struct device *dev;
+ struct drm_bridge *next_bridge;
+ void __iomem*regs;
+};
+
+static inline struct imx8mp_hdmi_pvi *
+to_imx8mp_hdmi_pvi(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct imx8mp_hdmi_pvi, bridge);
+}
+
+static int imx8mp_hdmi_pvi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+ struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+
+ return drm_bridge_attach(bridge->encoder, pvi->next_bridge,
+bridge, flags);
+}
+
+static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state)
+{
+ struct drm_atomic_state *state = bridge_state->base.state;
+ struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+ struct drm_connector_state *conn_state;
+ const struct drm_display_mode *mode;
+ struct drm_crtc_state *crtc_state;
+ struct drm_connector *connector;
+ u32 bus_flags, val;
+
+ connector = drm_atomic_get_new_connector_for_encoder(state,
bridge->encoder);
+ conn_state = drm_atomic_get_new_connector_state(state, connector);
+ crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+
+ if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
+ return;
+
+ mode = _state->adjusted_mode;
+
+ val = FIELD_PREP(PVI_CTRL_MODE_MASK, PVI_CTRL_MODE_LCDIF) | PVI_CTRL_EN;
+
+ if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+ val |= PVI_CTRL_OP_VSYNC_POL | PVI_CTRL_INP_VSYNC_POL;
+
+ if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+
[PATCH V7 1/2] dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
From: Lucas Stach
Add binding for the i.MX8MP HDMI parallel video interface block.
Signed-off-by: Lucas Stach
Reviewed-by: Laurent Pinchart
Reviewed-by: Conor Dooley
Signed-off-by: Adam Ford
---
V7: No Change
V6: Add s-o-b message for myself (Adam)
V5: I tried to help move this along, so I took Lucas' patch and
attempted to apply fixes based on feedback. I don't have
all the history, so apologies for that.
Removed the pipe character from the Description.
Increased the register size from 0x40 to 0x44.
diff --git
a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
new file mode 100644
index ..3377f152f319
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pvi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP HDMI Parallel Video Interface
+
+maintainers:
+ - Lucas Stach
+
+description:
+ The HDMI parallel video interface is a timing and sync generator block in the
+ i.MX8MP SoC, that sits between the video source and the HDMI TX controller.
+
+properties:
+ compatible:
+const: fsl,imx8mp-hdmi-pvi
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input from the LCDIF controller.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output to the HDMI TX controller.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - power-domains
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display-bridge@32fc4000 {
+compatible = "fsl,imx8mp-hdmi-pvi";
+reg = <0x32fc4000 0x44>;
+interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+power-domains = <_blk_ctrl IMX8MP_HDMIBLK_PD_PVI>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+pvi_from_lcdif3: endpoint {
+remote-endpoint = <_to_pvi>;
+};
+};
+
+port@1 {
+reg = <1>;
+pvi_to_hdmi_tx: endpoint {
+remote-endpoint = <_tx_from_pvi>;
+};
+};
+};
+};
--
2.43.0
[PATCH V6 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
From: Lucas Stach
This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
full timing generator and can switch between different video sources. On
the i.MX8MP however the only supported source is the LCDIF. The block
just needs to be powered up and told about the polarity of the video
sync signals to act in bypass mode.
Signed-off-by: Lucas Stach
Reviewed-by: Luca Ceresoli (v2)
Tested-by: Marek Vasut (v1)
Tested-by: Luca Ceresoli (v2)
Tested-by: Richard Leitner (v2)
Tested-by: Frieder Schrempf (v2)
Reviewed-by: Laurent Pinchart (v3)
Reviewed-by: Luca Ceresoli
Tested-by: Luca Ceresoli
Tested-by: Fabio Estevam
Signed-off-by: Adam Ford
---
V6: No change.
V5: I (Adam) tried to help move this along, so I took Lucas' patch and
attempted to apply fixes based on feedback. I don't have
all the history, so apologies for that.
No changes from V4 to V5
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index 5a4f3d58501e..a4d13331e320 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -3,6 +3,13 @@ if ARCH_MXC || COMPILE_TEST
config DRM_IMX_LDB_HELPER
tristate
+config DRM_IMX8MP_HDMI_PVI
+ tristate "Freescale i.MX8MP HDMI PVI bridge support"
+ depends on OF
+ help
+ Choose this to enable support for the internal HDMI TX Parallel
+ Video Interface found on the Freescale i.MX8MP SoC.
+
config DRM_IMX8QM_LDB
tristate "Freescale i.MX8QM LVDS display bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
index 2b0c2e44aa1b..e2c2106509fa 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
+obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
new file mode 100644
index ..9efe051a1e31
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright (C) 2022 Pengutronix, Lucas Stach
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HTX_PVI_CTRL 0x0
+#define PVI_CTRL_OP_VSYNC_POL BIT(18)
+#define PVI_CTRL_OP_HSYNC_POL BIT(17)
+#define PVI_CTRL_OP_DE_POLBIT(16)
+#define PVI_CTRL_INP_VSYNC_POLBIT(14)
+#define PVI_CTRL_INP_HSYNC_POLBIT(13)
+#define PVI_CTRL_INP_DE_POL BIT(12)
+#define PVI_CTRL_MODE_MASKGENMASK(2, 1)
+#define PVI_CTRL_MODE_LCDIF 2
+#define PVI_CTRL_EN BIT(0)
+
+struct imx8mp_hdmi_pvi {
+ struct drm_bridge bridge;
+ struct device *dev;
+ struct drm_bridge *next_bridge;
+ void __iomem*regs;
+};
+
+static inline struct imx8mp_hdmi_pvi *
+to_imx8mp_hdmi_pvi(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct imx8mp_hdmi_pvi, bridge);
+}
+
+static int imx8mp_hdmi_pvi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+ struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+
+ return drm_bridge_attach(bridge->encoder, pvi->next_bridge,
+bridge, flags);
+}
+
+static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state)
+{
+ struct drm_atomic_state *state = bridge_state->base.state;
+ struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+ struct drm_connector_state *conn_state;
+ const struct drm_display_mode *mode;
+ struct drm_crtc_state *crtc_state;
+ struct drm_connector *connector;
+ u32 bus_flags, val;
+
+ connector = drm_atomic_get_new_connector_for_encoder(state,
bridge->encoder);
+ conn_state = drm_atomic_get_new_connector_state(state, connector);
+ crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+
+ if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
+ return;
+
+ mode = _state->adjusted_mode;
+
+ val = FIELD_PREP(PVI_CTRL_MODE_MASK, PVI_CTRL_MODE_LCDIF) | PVI_CTRL_EN;
+
+ if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+ val |= PVI_CTRL_OP_VSYNC_POL | PVI_CTRL_INP_VSYNC_POL;
+
+ if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+ val |= PVI_CTRL_OP_HSYNC_POL | PVI_CTRL_INP_HSYNC_POL;
+
+ if (pvi->next_bridge->timings)
+
[PATCH V6 1/2] dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
From: Lucas Stach
Add binding for the i.MX8MP HDMI parallel video interface block.
Signed-off-by: Lucas Stach
Reviewed-by: Laurent Pinchart
Reviewed-by: Conor Dooley
Signed-off-by: Adam Ford
---
V6: Add s-o-b message for myself (Adam)
V5: I tried to help move this along, so I took Lucas' patch and
attempted to apply fixes based on feedback. I don't have
all the history, so apologies for that.
Removed the pipe character from the Description.
Increased the register size from 0x40 to 0x44.
diff --git
a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
new file mode 100644
index ..3377f152f319
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pvi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP HDMI Parallel Video Interface
+
+maintainers:
+ - Lucas Stach
+
+description:
+ The HDMI parallel video interface is a timing and sync generator block in the
+ i.MX8MP SoC, that sits between the video source and the HDMI TX controller.
+
+properties:
+ compatible:
+const: fsl,imx8mp-hdmi-pvi
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input from the LCDIF controller.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output to the HDMI TX controller.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - power-domains
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display-bridge@32fc4000 {
+compatible = "fsl,imx8mp-hdmi-pvi";
+reg = <0x32fc4000 0x44>;
+interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+power-domains = <_blk_ctrl IMX8MP_HDMIBLK_PD_PVI>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+pvi_from_lcdif3: endpoint {
+remote-endpoint = <_to_pvi>;
+};
+};
+
+port@1 {
+reg = <1>;
+pvi_to_hdmi_tx: endpoint {
+remote-endpoint = <_tx_from_pvi>;
+};
+};
+};
+};
--
2.43.0
[PATCH V5 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
From: Lucas Stach
This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
full timing generator and can switch between different video sources. On
the i.MX8MP however the only supported source is the LCDIF. The block
just needs to be powered up and told about the polarity of the video
sync signals to act in bypass mode.
Signed-off-by: Lucas Stach
Reviewed-by: Luca Ceresoli (v2)
Tested-by: Marek Vasut (v1)
Tested-by: Luca Ceresoli (v2)
Tested-by: Richard Leitner (v2)
Tested-by: Frieder Schrempf (v2)
Reviewed-by: Laurent Pinchart (v3)
Reviewed-by: Luca Ceresoli
Tested-by: Luca Ceresoli
Tested-by: Fabio Estevam
Signed-off-by: Adam Ford
---
V5: I (Adam) tried to help move this along, so I took Lucas' patch and
attempted to apply fixes based on feedback. I don't have
all the history, so apologies for that.
No changes from V4 to V5
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
b/drivers/gpu/drm/bridge/imx/Kconfig
index 5a4f3d58501e..a4d13331e320 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -3,6 +3,13 @@ if ARCH_MXC || COMPILE_TEST
config DRM_IMX_LDB_HELPER
tristate
+config DRM_IMX8MP_HDMI_PVI
+ tristate "Freescale i.MX8MP HDMI PVI bridge support"
+ depends on OF
+ help
+ Choose this to enable support for the internal HDMI TX Parallel
+ Video Interface found on the Freescale i.MX8MP SoC.
+
config DRM_IMX8QM_LDB
tristate "Freescale i.MX8QM LVDS display bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile
b/drivers/gpu/drm/bridge/imx/Makefile
index 2b0c2e44aa1b..e2c2106509fa 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
+obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
new file mode 100644
index ..9efe051a1e31
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright (C) 2022 Pengutronix, Lucas Stach
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HTX_PVI_CTRL 0x0
+#define PVI_CTRL_OP_VSYNC_POL BIT(18)
+#define PVI_CTRL_OP_HSYNC_POL BIT(17)
+#define PVI_CTRL_OP_DE_POLBIT(16)
+#define PVI_CTRL_INP_VSYNC_POLBIT(14)
+#define PVI_CTRL_INP_HSYNC_POLBIT(13)
+#define PVI_CTRL_INP_DE_POL BIT(12)
+#define PVI_CTRL_MODE_MASKGENMASK(2, 1)
+#define PVI_CTRL_MODE_LCDIF 2
+#define PVI_CTRL_EN BIT(0)
+
+struct imx8mp_hdmi_pvi {
+ struct drm_bridge bridge;
+ struct device *dev;
+ struct drm_bridge *next_bridge;
+ void __iomem*regs;
+};
+
+static inline struct imx8mp_hdmi_pvi *
+to_imx8mp_hdmi_pvi(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct imx8mp_hdmi_pvi, bridge);
+}
+
+static int imx8mp_hdmi_pvi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+ struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+
+ return drm_bridge_attach(bridge->encoder, pvi->next_bridge,
+bridge, flags);
+}
+
+static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state)
+{
+ struct drm_atomic_state *state = bridge_state->base.state;
+ struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
+ struct drm_connector_state *conn_state;
+ const struct drm_display_mode *mode;
+ struct drm_crtc_state *crtc_state;
+ struct drm_connector *connector;
+ u32 bus_flags, val;
+
+ connector = drm_atomic_get_new_connector_for_encoder(state,
bridge->encoder);
+ conn_state = drm_atomic_get_new_connector_state(state, connector);
+ crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
+
+ if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
+ return;
+
+ mode = _state->adjusted_mode;
+
+ val = FIELD_PREP(PVI_CTRL_MODE_MASK, PVI_CTRL_MODE_LCDIF) | PVI_CTRL_EN;
+
+ if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+ val |= PVI_CTRL_OP_VSYNC_POL | PVI_CTRL_INP_VSYNC_POL;
+
+ if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+ val |= PVI_CTRL_OP_HSYNC_POL | PVI_CTRL_INP_HSYNC_POL;
+
+ if (pvi->next_bridge->timings)
+ bus_fla
[PATCH V5 1/2] dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
From: Lucas Stach
Add binding for the i.MX8MP HDMI parallel video interface block.
Signed-off-by: Lucas Stach
Reviewed-by: Laurent Pinchart
Reviewed-by: Conor Dooley
---
V5: I tried to help move this along, so I took Lucas' patch and
attempted to apply fixes based on feedback. I don't have
all the history, so apologies for that.
Removed the pipe character from the Description.
Increased the register size from 0x40 to 0x44.
diff --git
a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
new file mode 100644
index ..3377f152f319
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pvi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8MP HDMI Parallel Video Interface
+
+maintainers:
+ - Lucas Stach
+
+description:
+ The HDMI parallel video interface is a timing and sync generator block in the
+ i.MX8MP SoC, that sits between the video source and the HDMI TX controller.
+
+properties:
+ compatible:
+const: fsl,imx8mp-hdmi-pvi
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input from the LCDIF controller.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output to the HDMI TX controller.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - power-domains
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display-bridge@32fc4000 {
+compatible = "fsl,imx8mp-hdmi-pvi";
+reg = <0x32fc4000 0x44>;
+interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+power-domains = <_blk_ctrl IMX8MP_HDMIBLK_PD_PVI>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+pvi_from_lcdif3: endpoint {
+remote-endpoint = <_to_pvi>;
+};
+};
+
+port@1 {
+reg = <1>;
+pvi_to_hdmi_tx: endpoint {
+remote-endpoint = <_tx_from_pvi>;
+};
+};
+};
+};
--
2.43.0
Re: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
On Fri, Dec 15, 2023 at 10:47 AM Fabio Estevam wrote: > > Hi Adam, > > On Fri, Dec 15, 2023 at 1:40 PM Adam Ford wrote: > > > I started looking into this today, but there appears to be some > > dependencies missing because the PVI is just one small portion of > > this. The PVI needs to interact with the hdmi_blk_ctrl and the hdmi > > transmitter itself. > > > > It looks like there was at least one attempt to push the hdmi driver, > > but we're also missing some hdmi power domain information, and the dri > > patchwork lists a bunch of proposed patches for the lcdif driver. I > > haven't looked through them all, so I don't know if they are > > necessary. I found a git repo with Lucas' stuff, but it's based on > > the 6.0 kernel, so it's fairly old. Either way it seems like there is > > more to the HDMI than just his one series. > > Here is the whole patchset that I tested against 6.6: > > https://patchwork.freedesktop.org/patch/485391/ > https://patchwork.freedesktop.org/patch/485392/ > https://patchwork.freedesktop.org/patch/485395/ > https://patchwork.freedesktop.org/patch/515299/ > https://patchwork.freedesktop.org/patch/515300/ > https://patchwork.kernel.org/project/linux-arm-kernel/patch/20220406153402.1265474-12-l.st...@pengutronix.de/ Thanks for the list. I was able to successfully build the stable 6.6 branch with those patches applied and I have the HDMI working. Unfortunately, I get build errors on the linux-next, so it's going to take me a little time to sort through all of this. I am thinking that it would be better to consolidate all these together into one series instead of piecemealing it. However, there are some items that can be submitted right away without significantly reworking them against linux-next. Do people have a preference? adam adam
Re: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
On Fri, Dec 15, 2023 at 8:23 AM Laurent Pinchart wrote: > > On Fri, Dec 15, 2023 at 10:31:27AM -0300, Fabio Estevam wrote: > > On Sun, Dec 10, 2023 at 2:35 PM Adam Ford wrote: > > > > > Lucas, > > > > > > It's been a few months since there has been any action. If you want, > > > I can help apply the suggestions that Laurent has and re-submit with > > > both of our names if you want. It would be nice to get this > > > integrated. > > > > It would be nice if you could re-submit the series. > > Yes, that would be nice. It shouldn't cause any issue, the patches will > retain Lucas' authorship. I started looking into this today, but there appears to be some dependencies missing because the PVI is just one small portion of this. The PVI needs to interact with the hdmi_blk_ctrl and the hdmi transmitter itself. It looks like there was at least one attempt to push the hdmi driver, but we're also missing some hdmi power domain information, and the dri patchwork lists a bunch of proposed patches for the lcdif driver. I haven't looked through them all, so I don't know if they are necessary. I found a git repo with Lucas' stuff, but it's based on the 6.0 kernel, so it's fairly old. Either way it seems like there is more to the HDMI than just his one series. adam > > -- > Regards, > > Laurent Pinchart
Re: [PATCH 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding
On Mon, Dec 11, 2023 at 9:33 PM Adam Ford wrote:
>
> When using video sync pulses, the HFP, HBP, and HSA are divided between
> the available lanes if there is more than one lane. For certain
> timings and lane configurations, the HFP may not be evenly divisible.
> If the HFP is rounded down, it ends up being too small which can cause
> some monitors to not sync properly. In these instances, adjust htotal
> and hsync to round the HFP up, and recalculate the htotal.
>
For anyone who's following this, I added a note which I apparently
forgot to save:
This adds support for 720p60 in the i.MX8M Plus.
NXP uses a look-up table in their downstream code to accomplish this.
Using this calculation, the driver can adjust without the need for a
complicated table and should be flexible for different timings and
resolutions depending on the monitor.
I don't have a DSI analyzer, and this appears to only work on
i.MX8M Plus but not Mini and Nano for some reason, despite their
having a similar DSI bridge.
When Frieder teste this, he reported no changes on the Kontrol BL
i.MX8MM: "So at least there is no negative impact in this case"
If someone else has an i.MX8MP, I would appreciate any feedback.
thanks
adam
> Tested-by: Frieder Schrempf # Kontron BL
> i.MX8MM with HDMI monitor
> Signed-off-by: Adam Ford
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 239d253a7d71..f5795da1d8bb 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1628,6 +1628,27 @@ static int samsung_dsim_atomic_check(struct drm_bridge
> *bridge,
> adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC);
> }
>
> + /*
> +* When using video sync pulses, the HFP, HBP, and HSA are divided
> between
> +* the available lanes if there is more than one lane. For certain
> +* timings and lane configurations, the HFP may not be evenly
> divisible.
> +* If the HFP is rounded down, it ends up being too small which can
> cause
> +* some monitors to not sync properly. In these instances, adjust
> htotal
> +* and hsync to round the HFP up, and recalculate the htotal. Through
> trial
> +* and error, it appears that the HBP and HSA do not appearto need
> the same
> +* correction that HFP does.
> +*/
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes >
> 1) {
> + int hfp = adjusted_mode->hsync_start -
> adjusted_mode->hdisplay;
> + int remainder = hfp % dsi->lanes;
> +
> + if (remainder) {
> + adjusted_mode->hsync_start += remainder;
> + adjusted_mode->hsync_end += remainder;
> + adjusted_mode->htotal += remainder;
> + }
> + }
> +
> return 0;
> }
>
> --
> 2.40.1
>
Re: [PATCH 1/2] drm/bridge: samsung-dsim: Set P divider based on min/max of fin pll
On Tue, Dec 12, 2023 at 2:25 AM Frieder Schrempf
wrote:
>
> Hi Adam,
>
> On 12.12.23 04:32, Adam Ford wrote:
> > The P divider should be set based on the min and max values of
> > the fin pll which may vary between different platforms.
> > These ranges are defined per platform, but hard-coded values
> > were used instead which resulted in a smaller range available
> > on the i.MX8M[MNP] than what was possible.
> >
> > Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock")
> > Signed-off-by: Adam Ford
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> > b/drivers/gpu/drm/bridge/samsung-dsim.c
> > index be5914caa17d..239d253a7d71 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -573,8 +573,8 @@ static unsigned long samsung_dsim_pll_find_pms(struct
> > samsung_dsim *dsi,
> > u16 _m, best_m;
> > u8 _s, best_s;
> >
> > - p_min = DIV_ROUND_UP(fin, (12 * MHZ));
> > - p_max = fin / (6 * MHZ);
> > + p_min = DIV_ROUND_UP(fin, (driver_data->pll_fin_max * MHZ));
> > + p_max = fin / (driver_data->pll_fin_min * MHZ);
>
> I did some tinkering with the PLL settings the other day and this is
> literally one of the things I came up with.
>
> So I'm happy to provide:
>
> Reviewed-by: Frieder Schrempf
> Tested-by: Frieder Schrempf
>
Thank you!
> Regarding the P divider, I'm also wondering if there is an upper limit
> for the p-value (not for the resulting fin_pll) that we should take into
> account, too. The problem is that we have conflicts in the documentation
> (again) so we don't really know what the correct limit would be.
>
> There are the following ranges given in the RMs:
>
> * 1..63 (i.MX8MM RM 13.7.8.18.4)
> * 1..33 (i.MX8MM RM 13.7.10.1)
> * 1..63 (i.MX8MP RM 13.2.3.1.5.2)
> * 1..63 (i.MX8MP RM 13.7.2.4)
1...63 (i.IMX8MN RM 13.7.2.4)
>
> Unfortunately there are similar discrepancies for the other parameters
> and limits.
For what it's worth, I compared these values to the NXP downstream
branch [1], and they seemed to indicate the values were as follows:
.p = { .min = 1, .max = 63, },
.m = { .min = 64, .max = 1023, },
.s = { .min = 0, .max = 5, },
.k = { .min = 0, .max = 32768, }, /* abs(k) */
.fin = { .min = 6000, .max = 30, }, /* in KHz */
.fpref = { .min = 2000, .max = 3, }, /* in KHz */
.fvco = { .min = 105, .max = 210, }, /* in KHz */
In a previous commit [2], I mentioned the fact that I reached out to
NXP asking about the discrepancies and my NXP Rep and I received the
response:
"Yes it is definitely wrong, the one that is part of the NOTE in
MIPI_DPHY_M_PLLPMS register table against PMS_P, PMS_M and PMS_S is
not correct. I will report this to Doc team, the one customer should
be take into account is the Table 13-40 DPHY PLL Parameters and the
Note above."
adam
[1] -
https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/gpu/drm/imx/sec_mipi_pll_1432x.h#L38C1-L47C1
[2] -
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/bridge/samsung-dsim.c?h=next-20231212=54f1a83c72250b182fa7722b0c5f6eb5e769598d
>
> Thanks
> Frieder
>
> >
> > for (_p = p_min; _p <= p_max; ++_p) {
> > for (_s = 0; _s <= 5; ++_s) {
>
[PATCH 2/2] drm/bridge: samsung-dsim: Fix porch calcalcuation rounding
When using video sync pulses, the HFP, HBP, and HSA are divided between
the available lanes if there is more than one lane. For certain
timings and lane configurations, the HFP may not be evenly divisible.
If the HFP is rounded down, it ends up being too small which can cause
some monitors to not sync properly. In these instances, adjust htotal
and hsync to round the HFP up, and recalculate the htotal.
Tested-by: Frieder Schrempf # Kontron BL i.MX8MM
with HDMI monitor
Signed-off-by: Adam Ford
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 239d253a7d71..f5795da1d8bb 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1628,6 +1628,27 @@ static int samsung_dsim_atomic_check(struct drm_bridge
*bridge,
adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
DRM_MODE_FLAG_PVSYNC);
}
+ /*
+* When using video sync pulses, the HFP, HBP, and HSA are divided
between
+* the available lanes if there is more than one lane. For certain
+* timings and lane configurations, the HFP may not be evenly divisible.
+* If the HFP is rounded down, it ends up being too small which can
cause
+* some monitors to not sync properly. In these instances, adjust htotal
+* and hsync to round the HFP up, and recalculate the htotal. Through
trial
+* and error, it appears that the HBP and HSA do not appearto need the
same
+* correction that HFP does.
+*/
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes > 1)
{
+ int hfp = adjusted_mode->hsync_start - adjusted_mode->hdisplay;
+ int remainder = hfp % dsi->lanes;
+
+ if (remainder) {
+ adjusted_mode->hsync_start += remainder;
+ adjusted_mode->hsync_end += remainder;
+ adjusted_mode->htotal += remainder;
+ }
+ }
+
return 0;
}
--
2.40.1
[PATCH 1/2] drm/bridge: samsung-dsim: Set P divider based on min/max of fin pll
The P divider should be set based on the min and max values of
the fin pll which may vary between different platforms.
These ranges are defined per platform, but hard-coded values
were used instead which resulted in a smaller range available
on the i.MX8M[MNP] than what was possible.
Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock")
Signed-off-by: Adam Ford
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index be5914caa17d..239d253a7d71 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -573,8 +573,8 @@ static unsigned long samsung_dsim_pll_find_pms(struct
samsung_dsim *dsi,
u16 _m, best_m;
u8 _s, best_s;
- p_min = DIV_ROUND_UP(fin, (12 * MHZ));
- p_max = fin / (6 * MHZ);
+ p_min = DIV_ROUND_UP(fin, (driver_data->pll_fin_max * MHZ));
+ p_max = fin / (driver_data->pll_fin_min * MHZ);
for (_p = p_min; _p <= p_max; ++_p) {
for (_s = 0; _s <= 5; ++_s) {
--
2.40.1
Re: [PATCH v3 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
On Wed, Sep 20, 2023 at 3:57 PM Laurent Pinchart
wrote:
>
> Hi Lucas,
>
> Thank you for the patch.
>
> On Wed, Sep 20, 2023 at 07:10:09PM +0200, Lucas Stach wrote:
> > This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
> > full timing generator and can switch between different video sources. On
> > the i.MX8MP however the only supported source is the LCDIF. The block
> > just needs to be powered up and told about the polarity of the video
> > sync signals to act in bypass mode.
> >
> > Signed-off-by: Lucas Stach
> > Reviewed-by: Luca Ceresoli (v2)
> > Tested-by: Marek Vasut (v1)
> > Tested-by: Luca Ceresoli (v2)
> > Tested-by: Richard Leitner (v2)
> > Tested-by: Frieder Schrempf (v2)
> > ---
> > drivers/gpu/drm/bridge/imx/Kconfig | 7 +
> > drivers/gpu/drm/bridge/imx/Makefile | 1 +
> > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 206 +++
> > 3 files changed, 214 insertions(+)
> > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> >
> > diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
> > b/drivers/gpu/drm/bridge/imx/Kconfig
> > index 9fae28db6aa7..3a4e663d922a 100644
> > --- a/drivers/gpu/drm/bridge/imx/Kconfig
> > +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> > @@ -3,6 +3,13 @@ if ARCH_MXC || COMPILE_TEST
> > config DRM_IMX_LDB_HELPER
> > tristate
> >
> > +config DRM_IMX8MP_HDMI_PVI
> > + tristate "Freescale i.MX8MP HDMI PVI bridge support"
> > + depends on OF
> > + help
> > + Choose this to enable support for the internal HDMI TX Parallel
> > + Video Interface found on the Freescale i.MX8MP SoC.
> > +
> > config DRM_IMX8QM_LDB
> > tristate "Freescale i.MX8QM LVDS display bridge"
> > depends on OF
> > diff --git a/drivers/gpu/drm/bridge/imx/Makefile
> > b/drivers/gpu/drm/bridge/imx/Makefile
> > index 8e2ebf3399a1..be9b4f9adb50 100644
> > --- a/drivers/gpu/drm/bridge/imx/Makefile
> > +++ b/drivers/gpu/drm/bridge/imx/Makefile
> > @@ -1,4 +1,5 @@
> > obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
> > +obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
> > obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
> > obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
> > obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
> > diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > new file mode 100644
> > index ..5ccd70c98187
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > @@ -0,0 +1,206 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +
> > +/*
> > + * Copyright (C) 2022 Pengutronix, Lucas Stach
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define HTX_PVI_CTRL 0x0
> > +#define PVI_CTRL_OP_VSYNC_POL BIT(18)
> > +#define PVI_CTRL_OP_HSYNC_POL BIT(17)
> > +#define PVI_CTRL_OP_DE_POL BIT(16)
> > +#define PVI_CTRL_INP_VSYNC_POL BIT(14)
> > +#define PVI_CTRL_INP_HSYNC_POL BIT(13)
> > +#define PVI_CTRL_INP_DE_POL BIT(12)
> > +#define PVI_CTRL_MODE_MASK GENMASK(2, 1)
> > +#define PVI_CTRL_MODE_LCDIF 2
> > +#define PVI_CTRL_EN BIT(0)
> > +
> > +struct imx8mp_hdmi_pvi {
> > + struct drm_bridge bridge;
> > + struct device *dev;
> > + struct drm_bridge *next_bridge;
> > + void __iomem*regs;
> > +};
> > +
> > +static inline struct imx8mp_hdmi_pvi *
> > +to_imx8mp_hdmi_pvi(struct drm_bridge *bridge)
> > +{
> > + return container_of(bridge, struct imx8mp_hdmi_pvi, bridge);
> > +}
> > +
> > +static int imx8mp_hdmi_pvi_bridge_attach(struct drm_bridge *bridge,
> > + enum drm_bridge_attach_flags flags)
> > +{
> > + struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> > +
> > + return drm_bridge_attach(bridge->encoder, pvi->next_bridge,
> > + bridge, flags);
> > +}
> > +
> > +static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
> > + struct drm_bridge_state
> > *bridge_state)
> > +{
> > + struct drm_atomic_state *state = bridge_state->base.state;
> > + struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> > + struct drm_connector_state *conn_state;
> > + const struct drm_display_mode *mode;
> > + struct drm_crtc_state *crtc_state;
> > + struct drm_connector *connector;
> > + u32 bus_flags, val;
> > +
> > + connector = drm_atomic_get_new_connector_for_encoder(state,
> > bridge->encoder);
> > + conn_state = drm_atomic_get_new_connector_state(state, connector);
> > + crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
> > +
> > + if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
> > +
Re: [PATCH] dt-bindings: display: adi, adv75xx: Document #sound-dai-cells
On Tue, Dec 5, 2023 at 7:28 PM Fabio Estevam wrote: > > From: Fabio Estevam > > When using audio from ADV7533 or ADV7535 and describing the audio > card via simple-audio-card, the '#sound-dai-cells' needs to be passed. > > Document the '#sound-dai-cells' property to fix the following > dt-schema warning: > Thanks for doing that. > imx8mn-beacon-kit.dtb: hdmi@3d: '#sound-dai-cells' does not match any of the > regexes: 'pinctrl-[0-9]+' > from schema $id: > http://devicetree.org/schemas/display/bridge/adi,adv7533.yaml# > Acked-by: Adam Ford > Signed-off-by: Fabio Estevam > --- > .../devicetree/bindings/display/bridge/adi,adv7533.yaml| 3 +++ > 1 file changed, 3 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml > b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml > index 987aa83c2649..e15ae072922e 100644 > --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml > @@ -89,6 +89,9 @@ properties: > $ref: /schemas/types.yaml#/definitions/uint32 > enum: [ 1, 2, 3, 4 ] > > + '#sound-dai-cells': > +const: 0 > + >ports: > description: >The ADV7533/35 has two video ports and one audio port. > -- > 2.34.1 >
Re: [RFC] drm: bridge: samsung-dsim: Recalculate timings when rounding HFP up
On Thu, Oct 26, 2023 at 1:12 PM Frieder Schrempf wrote: > > Hi Adam, > > On 13.10.23 05:10, Adam Ford wrote: > > When using video sync pulses, the HFP, HBP, and HSA are divided between > > the available lanes if there is more than one lane. For certain > > timings and lane configurations, the HFP may not be evenly divisible > > and it gets rounded down which can cause certain resolutions and > > refresh rates to not sync. > > > > ie. 720p60 on some monitors show hss of 1390 and hdisplay of 1280. This > > yields an HFP of 110. When taking the HFP of 110 divides along 4 lanes, > > the result is 27.5 which rounds down to 27 and causes some monitors not > > to sync. > > > > The solultion is to round HFP up by finding the remainder of HFP / > > the number of lanes and increasing the hsync_start, hsync_end, and > > htotal to compensate when there is a remainder. > > > > Signed-off-by: Adam Ford > > --- > > This adds support for 720p60 in the i.MX8M Plus. > > > > NXP uses a look-up table in their downstream code to accomplish this. > > Using this calculation, the driver can adjust without the need for a > > complicated table and should be flexible for different timings and > > resolutions depending on the monitor. > > > > I don't have a DSI analyzer, and this appears to only work on > > i.MX8M Plus but not Mini and Nano for some reason, despite their > > having a similar DSI bridge. > > I just want to report that I have tested this patch (on top of current > linux-next) on our Kontron BL i.MX8MM board with the ADV7535 bridge and > I don't see any change when trying the 30 different modes the monitor > reports as supported. 18 of those work and 12 don't work. Thanks for testing this. I didn't see any regressions on my Mini or Nano either, but I did see the 720p60 now works on i.MX8M Plus (but not on Mini/Nano). I am not sure why, and I don't have a DSI analyzer. > > So at least there is no negative impact in this case. At least nothing broke. :-) > > Tested-by: Frieder Schrempf # Kontron BL > i.MX8MM with HDMI monitor I'll add your T-b when I post it again. > > Thanks > Frieder
[RFC] drm: bridge: samsung-dsim: Recalculate timings when rounding HFP up
When using video sync pulses, the HFP, HBP, and HSA are divided between
the available lanes if there is more than one lane. For certain
timings and lane configurations, the HFP may not be evenly divisible
and it gets rounded down which can cause certain resolutions and
refresh rates to not sync.
ie. 720p60 on some monitors show hss of 1390 and hdisplay of 1280. This
yields an HFP of 110. When taking the HFP of 110 divides along 4 lanes,
the result is 27.5 which rounds down to 27 and causes some monitors not
to sync.
The solultion is to round HFP up by finding the remainder of HFP /
the number of lanes and increasing the hsync_start, hsync_end, and
htotal to compensate when there is a remainder.
Signed-off-by: Adam Ford
---
This adds support for 720p60 in the i.MX8M Plus.
NXP uses a look-up table in their downstream code to accomplish this.
Using this calculation, the driver can adjust without the need for a
complicated table and should be flexible for different timings and
resolutions depending on the monitor.
I don't have a DSI analyzer, and this appears to only work on
i.MX8M Plus but not Mini and Nano for some reason, despite their
having a similar DSI bridge.
diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
b/drivers/gpu/drm/bridge/samsung-dsim.c
index be5914caa17d..5564e85f6b63 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1628,6 +1628,26 @@ static int samsung_dsim_atomic_check(struct drm_bridge
*bridge,
adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
DRM_MODE_FLAG_PVSYNC);
}
+ /*
+* When using video sync pulses, the HFP, HBP, and HSA are divided
between
+* the available lanes if there is more than one lane. For certain
+* timings and lane configurations, the HFP may not be evenly divisible.
+* This can cause HFP to round down, and it ends up being too small
which can
+* cause some monitors to not sync properly. In these instances, round
HFP up
+* and adjust htotal to compensate. Through trial and error, it appears
that
+* the HBP and HSA do not appear to need the same correction that HFP
does.
+*/
+ if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE && dsi->lanes > 1)
{
+ int hfp = adjusted_mode->hsync_start - adjusted_mode->hdisplay;
+ int remainder = hfp % dsi->lanes;
+
+ if (remainder) {
+ adjusted_mode->hsync_start += remainder;
+ adjusted_mode->hsync_end += remainder;
+ adjusted_mode->htotal += remainder;
+ }
+ }
+
return 0;
}
--
2.40.1
Re: [PATCH 1/5] drm/bridge: samsung-dsim: add more mipi-dsi device debug information
On Sun, Sep 3, 2023 at 8:05 PM Inki Dae wrote: > > 2023년 8월 29일 (화) 오전 7:38, Adam Ford 님이 작성: > > > > On Mon, Aug 28, 2023 at 10:59 AM Michael Tretter > > wrote: > > > > > > From: Marco Felsch > > > > > > Since the MIPI configuration can be changed on demand it is very useful > > > to print more MIPI settings during the MIPI device attach step. > > > > > > Signed-off-by: Marco Felsch > > > Signed-off-by: Michael Tretter > > > > Reviewed-by: Adam Ford #imx8mm-beacon > > Tested-by: Adam Ford #imx8mm-beacon > > Reviewed-by: Inki Dae > Acked-by: Inki Dae What needs to be done in order to get this accepted? This series is a very nice improvement in i.MX8M Mini / Nano. adam > > > > > > --- > > > drivers/gpu/drm/bridge/samsung-dsim.c | 5 - > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c > > > b/drivers/gpu/drm/bridge/samsung-dsim.c > > > index 73ec60757dbc..6778f1751faa 100644 > > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c > > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > > > @@ -1711,7 +1711,10 @@ static int samsung_dsim_host_attach(struct > > > mipi_dsi_host *host, > > > return ret; > > > } > > > > > > - DRM_DEV_INFO(dev, "Attached %s device\n", device->name); > > > + DRM_DEV_INFO(dev, "Attached %s device (lanes:%d bpp:%d > > > mode-flags:0x%lx)\n", > > > +device->name, device->lanes, > > > +mipi_dsi_pixel_format_to_bpp(device->format), > > > +device->mode_flags); > > > > > > drm_bridge_add(>bridge); > > > > > > > > > -- > > > 2.39.2 > > >
Re: [PATCH 0/5] drm/bridge: samsung-dsim: fix various modes with ADV7535 bridge
On Mon, Aug 28, 2023 at 11:13 AM Adam Ford wrote: > > On Mon, Aug 28, 2023 at 10:59 AM Michael Tretter > wrote: > > > > I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter, > > which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few > > modes were working, but in many modes my monitor stayed dark. > > > > This series fixes the Samsung DSIM bridge driver to bring up a few more > > modes: > > > > The driver read the rate of the PLL ref clock only during probe. > > However, if the clock is re-parented to the VIDEO_PLL, changes to the > > pixel clock have an effect on the PLL ref clock. Therefore, the driver > > must read and potentially update the PLL ref clock on every modeset. > > > > I also found that the rounding mode of the porches and active area has > > an effect on the working modes. If the driver rounds up instead of > > rounding down and be calculates them in Hz instead of kHz, more modes > > start to work. > > > > The following table shows the modes that were working in my test without > > this patch set and the modes that are working now: > > > > |Mode | Before | Now | > > | 1920x1080-60.00 | X | X | > > | 1920x1080-59.94 || X | > > | 1920x1080-50.00 || X | > > | 1920x1080-30.00 || X | > > | 1920x1080-29.97 || X | > > | 1920x1080-25.00 || X | > > | 1920x1080-24.00 || | > > | 1920x1080-23.98 || | > > | 1680x1050-59.88 || X | > > | 1280x1024-75.03 | X | X | > > | 1280x1024-60.02 | X | X | > > | 1200x960-59.99 || X | > > | 1152x864-75.00 | X | X | > > | 1280x720-60.00 || | > > | 1280x720-59.94 || | > > | 1280x720-50.00 || X | > > | 1024x768-75.03 || X | > > | 1024x768-60.00 || X | > > | 800x600-75.00 | X | X | > > | 800x600-60.32 | X | X | > > | 720x576-50.00 | X | X | > > | 720x480-60.00 || | > > | 720x480-59.94 | X | | > > | 640x480-75.00 | X | X | > > | 640x480-60.00 || X | > > | 640x480-59.94 || X | > > | 720x400-70.08 || | > > > > Nice! > > > Interestingly, the 720x480-59.94 mode stopped working. However, I am > > able to bring up the 720x480 modes by manually hacking the active area > > (hsa) to 40 and carefully adjusting the clocks, but something still > > seems to be off. > > Checkout my > > branch: > https://github.com/aford173/linux/commit/183cf6d154afeb9b0300500b09d7b8ec53047a12 > > I found that certain resolutions don't properly round, and it seemed > to be related to the size of HFP. HFP of 110 when divded between 4 > lanes, required a round-up, but then I had to recalculate the rest of > the horizontal timings to compensate. > > I was going to push that as an RFC, but I will investigate your patch > series first. With my small rounding correction, I am able to get > 720x480 and 720p on my imx8mp, but not my mini/nano, so I am hoping > your patch series fixes that issue for me. > > > > > Unfortunately, a few more modes are still not working at all. The NXP > > downstream kernel has some quirks to handle some of the modes especially > > wrt. to the porches, but I cannot figure out, what the driver should > > actually do in these cases. Maybe there is still an error in the > > calculation of the porches and someone at NXP can chime in. > > Hopefully the comment in my above patch explains how the calculation > is corrected and adjusted to get some of the missing resolutions. I tested my above patch and it works to sync 720p-60 on my imx8mp, but it doesn't seem to sync on my imx8mm using the same monitor and HDMI cable. I don't have a DSI analyzer, so I might still send out a modified version of my patch as an RFC once this gets approved. adam > > > Michael > > > > Signed-off-by: Michael Tretter > > I'll try to reivew this week and respond with my feedback. > > adam > > > --- > > Marco Felsch (1): > > drm/bridge: samsung-dsim: add more mipi-dsi device debug information > > > > Michael Tretter (4): > > drm/bridge: samsung-dsim: reread ref clock before configuring PLL > > drm/bridge: samsung-dsim: update PLL reference clock > > drm/bridge: samsung-dsim: adjust porches by rounding up > > drm/bridge: samsung-dsim: calculate porches in Hz > > > > drivers/gpu/drm/bridge/samsung-dsim.c | 42 > > +-- > > include/drm/bridge/samsung-dsim.h | 1 + > > 2 files changed, 31 insertions(+), 12 deletions(-) > > --- > > base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c > > change-id: 20230818-samsung-dsim-42346444bce5 > > > > Best regards, > > -- > > Michael Tretter > >
Re: [PATCH 5/5] drm/bridge: samsung-dsim: calculate porches in Hz
On Mon, Aug 28, 2023 at 10:59 AM Michael Tretter
wrote:
>
> Calculating the byte_clk in kHz is imprecise for a hs_clock of 55687500
> Hz, which may be used with a pixel clock of 74.25 MHz with mode
> 1920x1080-30.
>
> Fix the calculation by using HZ instead of kHZ.
>
> This requires to change the type to u64 to prevent overflows of the
> integer type.
>
I would argue this needs a fixes tag since the previous calculations
were not accurately generated for many resolutions and refresh rates.
Reviewed-by: Adam Ford #imx8mm-beacon
Tested-by: Adam Ford #imx8mm-beacon
> Signed-off-by: Michael Tretter
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 459be953be55..eb7aca2b9ab7 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -973,10 +973,12 @@ static void samsung_dsim_set_display_mode(struct
> samsung_dsim *dsi)
> u32 reg;
>
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> - int byte_clk_khz = dsi->hs_clock / 1000 / 8;
> - int hfp = DIV_ROUND_UP((m->hsync_start - m->hdisplay) *
> byte_clk_khz, m->clock);
> - int hbp = DIV_ROUND_UP((m->htotal - m->hsync_end) *
> byte_clk_khz, m->clock);
> - int hsa = DIV_ROUND_UP((m->hsync_end - m->hsync_start) *
> byte_clk_khz, m->clock);
> + u64 byte_clk = dsi->hs_clock / 8;
> + u64 pix_clk = m->clock * 1000;
> +
> + int hfp = DIV64_U64_ROUND_UP((m->hsync_start - m->hdisplay) *
> byte_clk, pix_clk);
> + int hbp = DIV64_U64_ROUND_UP((m->htotal - m->hsync_end) *
> byte_clk, pix_clk);
> + int hsa = DIV64_U64_ROUND_UP((m->hsync_end - m->hsync_start)
> * byte_clk, pix_clk);
>
> /* remove packet overhead when possible */
> hfp = max(hfp - 6, 0);
>
> --
> 2.39.2
>
Re: [PATCH 4/5] drm/bridge: samsung-dsim: adjust porches by rounding up
On Mon, Aug 28, 2023 at 1:26 PM Fabio Estevam wrote: > > Hi Michael, > > On Mon, Aug 28, 2023 at 12:59 PM Michael Tretter > wrote: > > > > The porches must be rounded up to make the samsung-dsim work. ...at some resolutions and refresh rates. > > The commit log could be improved here. > > The way it is written gives the impression that samsung-dsim does not > work currently. This is a big improvement in the number of resolutions and refresh rates. Reviewed-by: Adam Ford #imx8mm-beacon Tested-by: Adam Ford #imx8mm-beacon
Re: [PATCH 1/5] drm/bridge: samsung-dsim: add more mipi-dsi device debug information
On Mon, Aug 28, 2023 at 10:59 AM Michael Tretter wrote: > > From: Marco Felsch > > Since the MIPI configuration can be changed on demand it is very useful > to print more MIPI settings during the MIPI device attach step. > > Signed-off-by: Marco Felsch > Signed-off-by: Michael Tretter Reviewed-by: Adam Ford #imx8mm-beacon Tested-by: Adam Ford #imx8mm-beacon > --- > drivers/gpu/drm/bridge/samsung-dsim.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c > b/drivers/gpu/drm/bridge/samsung-dsim.c > index 73ec60757dbc..6778f1751faa 100644 > --- a/drivers/gpu/drm/bridge/samsung-dsim.c > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c > @@ -1711,7 +1711,10 @@ static int samsung_dsim_host_attach(struct > mipi_dsi_host *host, > return ret; > } > > - DRM_DEV_INFO(dev, "Attached %s device\n", device->name); > + DRM_DEV_INFO(dev, "Attached %s device (lanes:%d bpp:%d > mode-flags:0x%lx)\n", > +device->name, device->lanes, > +mipi_dsi_pixel_format_to_bpp(device->format), > +device->mode_flags); > > drm_bridge_add(>bridge); > > > -- > 2.39.2 >
Re: [PATCH 2/7] drm: adv7511: Add max_mode_clock variable to struct adv7511_chip_info
On Sun, Aug 13, 2023 at 1:05 PM Biju Das wrote:
>
> The ADV7533 supports a maximum pixel clock of 80MHz whereas it is 148.5MHz
> for ADV7535. Add max_mode_clock variable to struct adv7511_chip_info to
> handle this difference.
>
> Signed-off-by: Biju Das
For the series:
Reviewed-by: Adam Ford
Tested-by: Adam Ford #imx8mm-beacon
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 +
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 --
> drivers/gpu/drm/bridge/adv7511/adv7533.c | 2 +-
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> index 59e8ef10d72e..f8190442ffca 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -335,6 +335,7 @@ enum adv7511_type {
>
> struct adv7511_chip_info {
> enum adv7511_type type;
> + unsigned long max_mode_clock;
> };
>
> struct adv7511 {
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 013d8d640ef4..193b2d5bc7e6 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -1371,11 +1371,13 @@ static const struct adv7511_chip_info
> adv7511_chip_info = {
> };
>
> static const struct adv7511_chip_info adv7533_chip_info = {
> - .type = ADV7533
> + .type = ADV7533,
> + .max_mode_clock = 8
> };
>
> static const struct adv7511_chip_info adv7535_chip_info = {
> - .type = ADV7535
> + .type = ADV7535,
> + .max_mode_clock = 148500
> };
>
> static const struct i2c_device_id adv7511_i2c_ids[] = {
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> index c452c4dc1c3f..e92b27e0afd1 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> @@ -108,7 +108,7 @@ enum drm_mode_status adv7533_mode_valid(struct adv7511
> *adv,
> u8 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
>
> /* Check max clock for either 7533 or 7535 */
> - if (mode->clock > (adv->info->type == ADV7533 ? 8 : 148500))
> + if (mode->clock > adv->info->max_mode_clock)
> return MODE_CLOCK_HIGH;
>
> /* Check max clock for each lane */
> --
> 2.25.1
>
Re: [PATCH 3/5] drm/bridge: samsung-dsim: update PLL reference clock
On Mon, Aug 28, 2023 at 11:42 AM Marco Felsch wrote:
>
> On 23-08-28, Michael Tretter wrote:
> > The PLL requires a clock between 2 MHz and 30 MHz after the pre-divider.
> > The reference clock for the PLL may change due to changes to it's parent
> > clock. Thus, the frequency may be out of range or unsuited for
> > generating the high speed clock for MIPI DSI.
> >
> > Try to keep the pre-devider small, and set the reference clock close to
> > 30 MHz before recalculating the PLL configuration. Use a divider with a
> > power of two for the reference clock as this seems to work best in
> > my tests.
> >
> > Signed-off-by: Michael Tretter
> > ---
> > drivers/gpu/drm/bridge/samsung-dsim.c | 15 +--
> > 1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
> > b/drivers/gpu/drm/bridge/samsung-dsim.c
> > index da90c2038042..4de6e4f116db 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -611,10 +611,21 @@ static unsigned long samsung_dsim_set_pll(struct
> > samsung_dsim *dsi,
> > u16 m;
> > u32 reg;
> >
> > - if (dsi->pll_clk)
> > + if (dsi->pll_clk) {
> > + /*
> > + * Ensure that the reference clock is generated with a power
> > of
> > + * two divider from its parent, but close to the PLLs upper
> > + * limit of the valid range of 2 MHz to 30 MHz.
> > + */
> > + fin = clk_get_rate(clk_get_parent(dsi->pll_clk));
> > + while (fin > 30 * MHZ)
> > + fin = fin / 2;
>
> Really just a cosmetic nit: fin /= 2;
>
> Reviewed-by: Marco Felsch
>
> > + clk_set_rate(dsi->pll_clk, fin);
> > +
> > fin = clk_get_rate(dsi->pll_clk);
> > - else
> > + } else {
> > fin = dsi->pll_clk_rate;
> > + }
I don't have all the code style rules memorized. Did you run it
through checkpatch? I wonder if the braces here are appropriate for a
1-line after the else. If checkpatch is happy, I am fine with it.
adam
> > dev_dbg(dsi->dev, "PLL ref clock freq %lu\n", fin);
> >
> > fout = samsung_dsim_pll_find_pms(dsi, fin, freq, , , );
> >
> > --
> > 2.39.2
> >
> >
> >
Re: [PATCH 0/5] drm/bridge: samsung-dsim: fix various modes with ADV7535 bridge
On Mon, Aug 28, 2023 at 10:59 AM Michael Tretter wrote: > > I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter, > which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few > modes were working, but in many modes my monitor stayed dark. > > This series fixes the Samsung DSIM bridge driver to bring up a few more > modes: > > The driver read the rate of the PLL ref clock only during probe. > However, if the clock is re-parented to the VIDEO_PLL, changes to the > pixel clock have an effect on the PLL ref clock. Therefore, the driver > must read and potentially update the PLL ref clock on every modeset. > > I also found that the rounding mode of the porches and active area has > an effect on the working modes. If the driver rounds up instead of > rounding down and be calculates them in Hz instead of kHz, more modes > start to work. > > The following table shows the modes that were working in my test without > this patch set and the modes that are working now: > > |Mode | Before | Now | > | 1920x1080-60.00 | X | X | > | 1920x1080-59.94 || X | > | 1920x1080-50.00 || X | > | 1920x1080-30.00 || X | > | 1920x1080-29.97 || X | > | 1920x1080-25.00 || X | > | 1920x1080-24.00 || | > | 1920x1080-23.98 || | > | 1680x1050-59.88 || X | > | 1280x1024-75.03 | X | X | > | 1280x1024-60.02 | X | X | > | 1200x960-59.99 || X | > | 1152x864-75.00 | X | X | > | 1280x720-60.00 || | > | 1280x720-59.94 || | > | 1280x720-50.00 || X | > | 1024x768-75.03 || X | > | 1024x768-60.00 || X | > | 800x600-75.00 | X | X | > | 800x600-60.32 | X | X | > | 720x576-50.00 | X | X | > | 720x480-60.00 || | > | 720x480-59.94 | X | | > | 640x480-75.00 | X | X | > | 640x480-60.00 || X | > | 640x480-59.94 || X | > | 720x400-70.08 || | > Nice! > Interestingly, the 720x480-59.94 mode stopped working. However, I am > able to bring up the 720x480 modes by manually hacking the active area > (hsa) to 40 and carefully adjusting the clocks, but something still > seems to be off. Checkout my branch: https://github.com/aford173/linux/commit/183cf6d154afeb9b0300500b09d7b8ec53047a12 I found that certain resolutions don't properly round, and it seemed to be related to the size of HFP. HFP of 110 when divded between 4 lanes, required a round-up, but then I had to recalculate the rest of the horizontal timings to compensate. I was going to push that as an RFC, but I will investigate your patch series first. With my small rounding correction, I am able to get 720x480 and 720p on my imx8mp, but not my mini/nano, so I am hoping your patch series fixes that issue for me. > > Unfortunately, a few more modes are still not working at all. The NXP > downstream kernel has some quirks to handle some of the modes especially > wrt. to the porches, but I cannot figure out, what the driver should > actually do in these cases. Maybe there is still an error in the > calculation of the porches and someone at NXP can chime in. Hopefully the comment in my above patch explains how the calculation is corrected and adjusted to get some of the missing resolutions. > Michael > > Signed-off-by: Michael Tretter I'll try to reivew this week and respond with my feedback. adam > --- > Marco Felsch (1): > drm/bridge: samsung-dsim: add more mipi-dsi device debug information > > Michael Tretter (4): > drm/bridge: samsung-dsim: reread ref clock before configuring PLL > drm/bridge: samsung-dsim: update PLL reference clock > drm/bridge: samsung-dsim: adjust porches by rounding up > drm/bridge: samsung-dsim: calculate porches in Hz > > drivers/gpu/drm/bridge/samsung-dsim.c | 42 > +-- > include/drm/bridge/samsung-dsim.h | 1 + > 2 files changed, 31 insertions(+), 12 deletions(-) > --- > base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c > change-id: 20230818-samsung-dsim-42346444bce5 > > Best regards, > -- > Michael Tretter >
Re: [PATCH 1/7] drm: adv7511: Add struct adv7511_chip_info and use i2c_get_match_data()
On Sun, Aug 13, 2023 at 1:05 PM Biju Das wrote:
>
> Add struct adv7511_chip_info to handle hw differences between various
> chips rather checking against the 'type' variable in various places.
> Replace 'adv->type'->'info->type' by moving variable 'type' from
> struct adv7511 to struct adv7511_chip_info.
>
> Replace of_device_get_match_data() and ID lookup for retrieving match data
> with i2c_get_match_data() by adding adv7511_chip_info as device data for
> both OF and ID tables.
>
> Signed-off-by: Biju Das
Reviewed-by: Adam Ford
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511.h | 6 +-
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 68 +++-
> drivers/gpu/drm/bridge/adv7511/adv7533.c | 4 +-
> 3 files changed, 46 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> index 17445800248d..59e8ef10d72e 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -333,6 +333,10 @@ enum adv7511_type {
>
> #define ADV7511_MAX_ADDRS 3
>
> +struct adv7511_chip_info {
> + enum adv7511_type type;
> +};
> +
> struct adv7511 {
> struct i2c_client *i2c_main;
> struct i2c_client *i2c_edid;
> @@ -377,7 +381,7 @@ struct adv7511 {
> u8 num_dsi_lanes;
> bool use_timing_gen;
>
> - enum adv7511_type type;
> + const struct adv7511_chip_info *info;
> struct platform_device *audio_pdev;
>
> struct cec_adapter *cec_adap;
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 2611afd2c1c1..013d8d640ef4 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -354,7 +354,7 @@ static void __adv7511_power_on(struct adv7511 *adv7511)
> * first few seconds after enabling the output. On the other hand
> * adv7535 require to enable HPD Override bit for proper HPD.
> */
> - if (adv7511->type == ADV7535)
> + if (adv7511->info->type == ADV7535)
> regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
>ADV7535_REG_POWER2_HPD_OVERRIDE,
>ADV7535_REG_POWER2_HPD_OVERRIDE);
> @@ -373,7 +373,7 @@ static void adv7511_power_on(struct adv7511 *adv7511)
> */
> regcache_sync(adv7511->regmap);
>
> - if (adv7511->type == ADV7533 || adv7511->type == ADV7535)
> + if (adv7511->info->type == ADV7533 || adv7511->info->type == ADV7535)
> adv7533_dsi_power_on(adv7511);
> adv7511->powered = true;
> }
> @@ -381,7 +381,7 @@ static void adv7511_power_on(struct adv7511 *adv7511)
> static void __adv7511_power_off(struct adv7511 *adv7511)
> {
> /* TODO: setup additional power down modes */
> - if (adv7511->type == ADV7535)
> + if (adv7511->info->type == ADV7535)
> regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
>ADV7535_REG_POWER2_HPD_OVERRIDE, 0);
>
> @@ -397,7 +397,7 @@ static void __adv7511_power_off(struct adv7511 *adv7511)
> static void adv7511_power_off(struct adv7511 *adv7511)
> {
> __adv7511_power_off(adv7511);
> - if (adv7511->type == ADV7533 || adv7511->type == ADV7535)
> + if (adv7511->info->type == ADV7533 || adv7511->info->type == ADV7535)
> adv7533_dsi_power_off(adv7511);
> adv7511->powered = false;
> }
> @@ -682,7 +682,7 @@ adv7511_detect(struct adv7511 *adv7511, struct
> drm_connector *connector)
> status = connector_status_disconnected;
> } else {
> /* Renable HPD sensing */
> - if (adv7511->type == ADV7535)
> + if (adv7511->info->type == ADV7535)
> regmap_update_bits(adv7511->regmap,
> ADV7511_REG_POWER2,
>ADV7535_REG_POWER2_HPD_OVERRIDE,
>ADV7535_REG_POWER2_HPD_OVERRIDE);
> @@ -786,7 +786,7 @@ static void adv7511_mode_set(struct adv7511 *adv7511,
> else
> low_refresh_rate = ADV7511_LOW_REFRESH_RATE_NONE;
>
> - if (adv7511->type == ADV7511)
> + if (adv7511->info->type == ADV7511)
> regmap_update_bits(adv7511->regmap, 0xfb,
>0x6, low_refresh_rate << 1);
> else
> @@ -921,7 +921,7 @@ static enum drm_mode_st
Re: [PATCH 7/7] drm: adv7511: Add hpd_override_enable feature bit to struct adv7511_chip_info
On Fri, Aug 18, 2023 at 8:35 AM Biju Das wrote:
>
> Hi Adam Ford,
>
> Thanks for the feedback.
>
> > Subject: Re: [PATCH 7/7] drm: adv7511: Add hpd_override_enable feature bit
> > to struct adv7511_chip_info
> >
> > On Sun, Aug 13, 2023 at 1:06 PM Biju Das
> > wrote:
> > >
> > > As per spec, it is allowed to pulse the HPD signal to indicate that
> > > the EDID information has changed. Some monitors do this when they wake
> > > up from standby or are enabled. When the HPD goes low the adv7511 is
> > > reset and the outputs are disabled which might cause the monitor to go
> > > to standby again. To avoid this we ignore the HPD pin for the first
> > > few seconds after enabling the output. On the other hand,
> > > adv7535 require to enable HPD Override bit for proper HPD.
> > >
> > > Add hpd_override_enable feature bit to struct adv7511_chip_info to
> > > handle this scenario.
> > >
> > > While at it, drop the enum adv7511_type as it is unused.
> >
> > It seems like dropping adv7511_type is unrelated to the rest of the patch,
> > and I think it should be split from this into its own patch
>
> With this patch, there is no user for adv7511_type that is the
> reason it is added here. I thought that is the common practice.
>
I wasn't sure.
> Please correct me if that is not the case.
I'll defer to the maintainers. In general I like the series because
it reduces the number of compare evaluations. I'll try to run some
tests on a board that I have with a adv7535 this weekend.
adam
>
> Cheers,
> Biju
>
> >
> > adam
> > >
> > > Signed-off-by: Biju Das
> > > ---
> > > drivers/gpu/drm/bridge/adv7511/adv7511.h | 8 +---
> > > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12 +---
> > > 2 files changed, 6 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > index 627531f48f84..c523ac4c9bc8 100644
> > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > @@ -325,22 +325,16 @@ struct adv7511_video_config {
> > > struct hdmi_avi_infoframe avi_infoframe; };
> > >
> > > -enum adv7511_type {
> > > - ADV7511,
> > > - ADV7533,
> > > - ADV7535,
> > > -};
> > > -
> > > #define ADV7511_MAX_ADDRS 3
> > >
> > > struct adv7511_chip_info {
> > > - enum adv7511_type type;
> > > unsigned long max_mode_clock;
> > > unsigned long max_lane_freq;
> > > const char * const *supply_names;
> > > unsigned int num_supplies;
> > > unsigned has_dsi:1;
> > > unsigned link_config:1;
> > > + unsigned hpd_override_enable:1;
> > > };
> > >
> > > struct adv7511 {
> > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > index 6974c267b1d5..7b06a0a21685 100644
> > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > @@ -354,7 +354,7 @@ static void __adv7511_power_on(struct adv7511
> > *adv7511)
> > > * first few seconds after enabling the output. On the other hand
> > > * adv7535 require to enable HPD Override bit for proper HPD.
> > > */
> > > - if (adv7511->info->type == ADV7535)
> > > + if (adv7511->info->hpd_override_enable)
> > > regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
> > >ADV7535_REG_POWER2_HPD_OVERRIDE,
> > >ADV7535_REG_POWER2_HPD_OVERRIDE);
> > > @@ -381,7 +381,7 @@ static void adv7511_power_on(struct adv7511
> > > *adv7511) static void __adv7511_power_off(struct adv7511 *adv7511) {
> > > /* TODO: setup additional power down modes */
> > > - if (adv7511->info->type == ADV7535)
> > > + if (adv7511->info->hpd_override_enable)
> > > regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
> > >ADV7535_REG_POWER2_HPD_OVERRIDE,
> > > 0);
> > >
> > > @@ -682,7 +682,7 @@ adv7511_detect(struct adv7511 *adv7511, struct
> > drm_connector *connector)
> > >
