Re: [PATCH v2 00/12] drm/bridge: tc358768: Fixes and timings improvements

On 16/08/2023 14:25, Tomi Valkeinen wrote: > This series contains various fixes and cleanups for TC358768. The target > of this work is to get TC358768 working on Toradex's AM62 based board, > which has the following display pipeline: > > AM62 DPI -> TC358768 -> LT8912B -> HDMI connector > >

Re: [PATCH 11/11] drm/bridge: tc358768: Add DRM_BRIDGE_ATTACH_NO_CONNECTOR support

On 04/08/2023 13:44, Tomi Valkeinen wrote: I would rather have a commit message than a blank one. > Signed-off-by: Tomi Valkeinen > --- > drivers/gpu/drm/bridge/tc358768.c | 64 > +++ > 1 file changed, 45 insertions(+), 19 deletions(-) > > diff --git

Re: [PATCH 10/11] drm/bridge: tc358768: Attempt to fix DSI horizontal timings

On 04/08/2023 13:44, Tomi Valkeinen wrote: > The DSI horizontal timing calculations done by the driver seem to often > lead to underflows or overflows, depending on the videomode. > > There are two main things the current driver doesn't seem to get right: > DSI HSW and HFP, and VSDly. However,

Re: [PATCH 09/11] drm/bridge: tc358768: Fix tc358768_ns_to_cnt()

On 04/08/2023 13:44, Tomi Valkeinen wrote: > The tc358768_ns_to_cnt() is, most likely, supposed to do a div-round-up > operation, but it misses subtracting one from the dividend. > > Fix this by just using DIV_ROUND_UP(). Reviewed-by: Peter Ujfalusi > Fixes: ff1ca6397b1d ("drm/bridge: Add

Re: [PATCH 08/11] drm/bridge: tc358768: Clean up clock period code

On 04/08/2023 13:44, Tomi Valkeinen wrote: > The driver defines TC358768_PRECISION as 1000, and uses "nsk" to refer > to clock periods. The original author does not remember where all this > came from. I can confirm this! > Effectively the driver is using picoseconds as the unit for > clock

Re: [PATCH 07/11] drm/bridge: tc358768: Rename dsibclk to hsbyteclk

On 04/08/2023 13:44, Tomi Valkeinen wrote: > The Toshiba documentation talks about HSByteClk when referring to the > DSI HS byte clock, whereas the driver uses 'dsibclk' name. Also, in a > few places the driver calculates the byte clock from the DSI clock, even > if the byte clock is already

Re: [PATCH 06/11] drm/bridge: tc358768: Use dev for dbg prints, not priv->dev

On 04/08/2023 13:44, Tomi Valkeinen wrote: > Simplify the code by capturing the priv->dev value to dev variable, and > use it. Reviewed-by: Peter Ujfalusi > > Signed-off-by: Tomi Valkeinen > --- > drivers/gpu/drm/bridge/tc358768.c | 41 > --- > 1 file

Re: [PATCH 05/11] drm/bridge: tc358768: Print logical values, not raw register values

On 04/08/2023 13:44, Tomi Valkeinen wrote: > The driver debug prints DSI related timings as raw register values in > hex. It is much more useful to see the "logical" value of the timing, > not the register value. I'm a bit confused by the term 'logical' value, I think you meant decimal, easier

Re: [PATCH 04/11] drm/bridge: tc358768: Use struct videomode

On 04/08/2023 13:44, Tomi Valkeinen wrote: > The TC358768 documentation uses HFP, HBP, etc. values to deal with the > video mode, while the driver currently uses the DRM display mode > (htotal, hsync_start, etc). > > Change the driver to convert the DRM display mode to struct videomode, >

Re: [PATCH 03/11] drm/bridge: tc358768: Cleanup PLL calculations

On 04/08/2023 13:44, Tomi Valkeinen wrote: > As is quite common, some of TC358768's PLL register fields are to be > programmed with (value - 1). Specifically, the FBD and PRD, multiplier > and divider, are such fields. > > However, what the driver currently does is that it considers that the >

Re: [PATCH 02/11] drm/bridge: tc358768: Fix bit updates

On 04/08/2023 13:44, Tomi Valkeinen wrote: > The driver has a few places where it does: > > if (thing_is_enabled_in_config) > update_thing_bit_in_hw() > > This means that if the thing is _not_ enabled, the bit never gets > cleared. This affects the h/vsyncs and continuous DSI clock

Re: [PATCH 01/11] drm/bridge: tc358768: Fix use of uninitialized variable

On 04/08/2023 13:44, Tomi Valkeinen wrote: > smatch reports: > > drivers/gpu/drm/bridge/tc358768.c:223 tc358768_update_bits() error: > uninitialized symbol 'orig'. > > Fix this by bailing out from tc358768_update_bits() if the > tc358768_read() produces an error. > > Fixes: ff1ca6397b1d

Re: [PATCH 22/41] ARM: omap1: move plat/dma.c to mach/omap-dma.c

On 4/19/22 16:37, Arnd Bergmann wrote: > From: Arnd Bergmann > > Most of the interface functions in plat/dma.c are only used from the > USB driver, which is practically OMAP1 specific, except for compile > testing. > > The omap_get_plat_info(), omap_request_dma() and omap_free_dma() >

Re: [PATCH 21/41] ARM: omap1: dma: remove omap2 specific bits

On 4/19/22 16:37, Arnd Bergmann wrote: > From: Arnd Bergmann > > No part of plat-omap/dma.c is called on omap2 any more, so > anything omap2 specific in here can simply be removed. Reviewed-by: Peter Ujfalusi > Signed-off-by: Arnd Bergmann > --- > arch/arm/plat-omap/dma.c | 217

Re: [PATCH 19/41] ARM: omap: dma: make usb support optional

On 4/19/22 16:37, Arnd Bergmann wrote: > From: Arnd Bergmann > > Most of the plat-omap/dma.c code is specific to the USB > driver. The reason is simple: the omap_udc is the only driver which has not been ported to DMAengine. I had a patch if I recall to convert it, but I don't have a way to

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

Hi Alice, On 4/19/21 7:27 AM, Alice Guo (OSS) wrote: > From: Alice Guo > > Update all the code that use soc_device_match because add support for > soc_device_match returning -EPROBE_DEFER. > > Signed-off-by: Alice Guo > --- > drivers/bus/ti-sysc.c | 2 +- >