e_t dac_mux_show(struct device *dev,
> struct device_attribute *attr, c
> u32 reg;
> int rc;
>
> - rc = regmap_read(priv->scu, ASPEED_SCU_MISC_CTRL, ®);
> + rc = regmap_read(priv->scu, priv->dac_reg, ®);
> if (rc)
>
Hi Joel,
Sounds like a good idea! One comment though:
> @@ -111,10 +112,13 @@ static int aspeed_gfx_load(struct drm_device *drm)
> if (IS_ERR(priv->base))
> return PTR_ERR(priv->base);
>
> - priv->scu = syscon_regmap_lookup_by_compatible("aspeed,ast2500-scu");
> +
ut
> explaining why. This breaks the existing userspace, which is looking
> for 0xa8 in the lower byte.
>
> Change our implementation to expose the entire register.
As a userspace consumer of this:
Reviewed-by: Jeremy Kerr
Thanks!
Jeremy
7;re seeing with the ast driver on OpenPOWER
machines, thanks!
Acked-by: Jeremy Kerr
Cheers,
Jeremy
Hi Kuan-Wei,
> Several parts of the kernel contain redundant implementations of parity
> calculations for 32-bit and 64-bit values. Introduces generic
> parity32() and parity64() helpers in bitops.h, providing a standardized
> and optimized implementation.
More so than __builtin_parity() ?
I'm
Hi Yuri & Kuan-Wei:
> Thank you for sharing your opinion on this fixed parity(). Your
> arguments may or may not be important, depending on what existing
> users actually need. Unfortunately, Kuan-Wei didn't collect
> performance numbers and opinions from those proposed users.
For the fsi-i2c sid
Hi Kuan-Wei,
> Thanks for your feedback.
No problem!
> IIUC, from the fsi-i2c perspective, parity efficiency isn't a major
> concern,
Yes
> but you still prefer optimizing with methods like __builtin_parity().
No, it's not really about optimisation. In the case of this driver, my
preference w
