On Tue, May 16, 2023 at 5:27 AM Adam Ford wrote:
>
> The DPHY timings are currently hard coded. Since the input
> clock can be variable, the phy timings need to be variable
> too. To facilitate this, we need to cache the hs_clock
> based on what is generated from the PLL.
>
> The phy_mipi_dphy_ge
Hi Adam,
On 17.05.2023 04:55, Adam Ford wrote:
> On Mon, May 15, 2023 at 6:57 PM Adam Ford wrote:
>> The DPHY timings are currently hard coded. Since the input
>> clock can be variable, the phy timings need to be variable
>> too. To facilitate this, we need to cache the hs_clock
>> based on what
Am Montag, dem 15.05.2023 um 18:57 -0500 schrieb Adam Ford:
> The DPHY timings are currently hard coded. Since the input
> clock can be variable, the phy timings need to be variable
> too. To facilitate this, we need to cache the hs_clock
> based on what is generated from the PLL.
>
> The phy_mip
On Wed, May 17, 2023 at 6:28 AM Jagan Teki wrote:
>
> On Tue, May 16, 2023 at 5:27 AM Adam Ford wrote:
> >
> > The DPHY timings are currently hard coded. Since the input
> > clock can be variable, the phy timings need to be variable
> > too. To facilitate this, we need to cache the hs_clock
> >
On Tue, May 16, 2023 at 5:27 AM Adam Ford wrote:
>
> The DPHY timings are currently hard coded. Since the input
> clock can be variable, the phy timings need to be variable
> too. To facilitate this, we need to cache the hs_clock
> based on what is generated from the PLL.
>
> The phy_mipi_dphy_ge
On Mon, May 15, 2023 at 6:57 PM Adam Ford wrote:
>
> The DPHY timings are currently hard coded. Since the input
> clock can be variable, the phy timings need to be variable
> too. To facilitate this, we need to cache the hs_clock
> based on what is generated from the PLL.
>
> The phy_mipi_dphy_ge
