search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
10.8k stars 4.84k forks source link

drivers: media: pisp_be: Remove extras field from pisp_be_config #6140

Open naushir opened 1 month ago

naushir commented 1 month ago

Remove the various extras fields from struct pisp_be_config. These fields are not used by the driver nor the hardware, so do not belong in this structure.

Also put the tiles array at the top of struct pisp_be_tiles_config to ensure any size change to struct pisp_be_config does not move the tiles struct out of alignment.

This is a userland breaking change, and libpisp must be updated accordingly.

naushir commented 1 month ago

This will break userland, so best to merge this in together with the (soon to be) upstream changes.

naushir commented 1 month ago

@davidplowman and @njhollinghurst we won't merge this yet, but just a heads-up.

naushir commented 1 month ago

@jmondi this is something we should put into the next revision of your upstream driver.

njhollinghurst commented 1 month ago

I'm definitely a bit nervous about the driver/UAPI change....

But while we're at it why don't we remove the I/O addresses (buffer configs) as well, and start from GLOBAL_BAYER_ENABLE? The driver will never touch those address fields (instead it uses dma_addr_t addrs[]). I think the "test HAL" does use them for index numbers for TDN/Stitch buffer cycling, but I'm sure we could come up with a different and no worse hack.

naushir commented 1 month ago

But while we're at it why don't we remove the I/O addresses (buffer configs) as well, and start from GLOBAL_BAYER_ENABLE? The driver will never touch those address fields (instead it uses dma_addr_t addrs[]). I think the "test HAL" does use them for index numbers for TDN/Stitch buffer cycling, but I'm sure we could come up with a different and no worse hack.

Done!

jmondi commented 1 month ago

@jmondi this is something we should put into the next revision of your upstream driver.

I'll take this in and take the occasion to send a new version.

If mainline does not provide any additional feedback/comments on the driver, I'll send a pull request and that's it, the series has been there for quite some time. We're late already for the 6.10 merge window, but as soon as v6.10-rc1 is out, I'll make sure the driver is collected