Re: [PATCH v5 1/4] drm/i915: Keep track of pwm-related backlight hooks separately
On Thu, Jan 7, 2021 at 2:52 PM Lyude Paul wrote:
>
> Currently, every different type of backlight hook that i915 supports is
> pretty straight forward - you have a backlight, probably through PWM
> (but maybe DPCD), with a single set of platform-specific hooks that are
> used for controlling it.
>
> HDR backlights, in particular VESA and Intel's HDR backlight
> implementations, can end up being more complicated. With Intel's
> proprietary interface, HDR backlight controls always run through the
> DPCD. When the backlight is in SDR backlight mode however, the driver
> may need to bypass the TCON and control the backlight directly through
> PWM.
>
> So, in order to support this we'll need to split our backlight callbacks
> into two groups: a set of high-level backlight control callbacks in
> intel_panel, and an additional set of pwm-specific backlight control
> callbacks. This also implies a functional changes for how these
> callbacks are used:
>
> * We now keep track of two separate backlight level ranges, one for the
> high-level backlight, and one for the pwm backlight range
> * We also keep track of backlight enablement and PWM backlight
> enablement separately
> * Since the currently set backlight level might not be the same as the
> currently programmed PWM backlight level, we stop setting
> panel->backlight.level with the currently programmed PWM backlight
> level in panel->backlight.pwm_funcs->setup(). Instead, we rely
> on the higher level backlight control functions to retrieve the
> current PWM backlight level (in this case, intel_pwm_get_backlight()).
> Note that there are still a few PWM backlight setup callbacks that
> do actually need to retrieve the current PWM backlight level, although
> we no longer save this value in panel->backlight.level like before.
>
> Additionally, we drop the call to lpt_get_backlight() in
> lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
> we get from it and only write it back if we're in CPU mode, and switching
> to PCH mode. The reason for this is because in the original codepath for
> this, it was expected that the intel_panel_bl_funcs->setup() hook would be
> responsible for fetching the initial backlight level. On lpt systems, the
> only time we could ever be in PCH backlight mode is during the initial
> driver load - meaning that outside of the setup() hook, lpt_get_backlight()
> will always be the callback used for retrieving the current backlight
> level. After this patch we still need to fetch and write-back the PCH
> backlight value if we're switching from CPU mode to PCH, but because
> intel_pwm_setup_backlight() will retrieve the backlight level after setup()
> using the get() hook, which always ends up being lpt_get_backlight(). Thus
> - an additional call to lpt_get_backlight() in lpt_setup_backlight() is
> made redundant.
>
> v5:
> * Fix indenting warnings from checkpatch
> v4:
> * Fix commit message
> * Remove outdated comment in intel_panel.c
> * Rename pwm_(min|max) to pwm_level_(min|max)
> * Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
> indirection
> * Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
> intel_panel_init_backlight_funcs() quite yet
> v3:
> * Reuse intel_panel_bl_funcs() for pwm_funcs
> * Explain why we drop lpt_get_backlight()
>
> Signed-off-by: Lyude Paul
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
Whole series is:
Tested-by: Vasily Khoruzhick
> ---
> .../drm/i915/display/intel_display_types.h| 4 +
> drivers/gpu/drm/i915/display/intel_panel.c| 333 ++
> 2 files changed, 187 insertions(+), 150 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 1067bd073c95..ee5c2d50b81a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -252,6 +252,9 @@ struct intel_panel {
> bool alternate_pwm_increment; /* lpt+ */
>
> /* PWM chip */
> + u32 pwm_level_min;
> + u32 pwm_level_max;
> + bool pwm_enabled;
> bool util_pin_active_low; /* bxt+ */
> u8 controller; /* bxt+ only */
> struct pwm_device *pwm;
> @@ -263,6 +266,7 @@ struct intel_panel {
> struct backlight_device *device;
>
> const struct intel_panel_bl_funcs *funcs;
> + const struct intel_panel_bl_funcs *pwm_funcs;
> void (*power)(struct intel_connector *, bool enable);
> } backlig
Re: [RFC v2 1/8] drm/i915/dp: Program source OUI on eDP panels
On Wed, Sep 16, 2020 at 10:19 AM Lyude Paul wrote:
>
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will just read zeroes.
>
> We also take care not to reprogram the source OUI if it already matches
> what we expect. This is just to be careful so that we don't accidentally
> take the panel out of any backlight control modes we found it in.
>
> v2:
> * Add careful parameter to intel_edp_init_source_oui() to avoid
> re-writing the source OUI if it's already been set during driver
> initialization
>
> Signed-off-by: Lyude Paul
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
Hi Lyude,
Sorry for a late reply.
Whole series is:
Tested-by: Vasily Khoruzhick
Regards,
Vasily
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4bd10456ad188..7db2b6a3cd52e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3424,6 +3424,29 @@ void intel_dp_sink_set_decompression_state(struct
> intel_dp *intel_dp,
> enable ? "enable" : "disable");
> }
>
> +static void
> +intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 oui[] = { 0x00, 0xaa, 0x01 };
> + u8 buf[3] = { 0 };
> +
> + /*
> +* During driver init, we want to be careful and avoid changing the
> source OUI if it's
> +* already set to what we want, so as to avoid clearing any state by
> accident
> +*/
> + if (careful) {
> + if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf,
> sizeof(buf)) < 0)
> + drm_err(>drm, "Failed to read source OUI\n");
> +
> + if (memcmp(oui, buf, sizeof(oui)) == 0)
> + return;
> + }
> +
> + if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui,
> sizeof(oui)) < 0)
> + drm_err(>drm, "Failed to write source OUI\n");
> +}
> +
> /* If the sink supports it, try to set the power state appropriately */
> void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> {
> @@ -3443,6 +3466,10 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int
> mode)
> } else {
> struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
>
> + /* Write the source OUI as early as possible */
> + if (intel_dp_is_edp(intel_dp))
> + intel_edp_init_source_oui(intel_dp, false);
> +
> /*
> * When turning on, we need to retry for 1ms to give the sink
> * time to wake up.
> @@ -4607,6 +4634,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> intel_dp_get_dsc_sink_cap(intel_dp);
>
> + /*
> +* If needed, program our source OUI so we can make various
> Intel-specific AUX services
> +* available (such as HDR backlight controls)
> +*/
> + intel_edp_init_source_oui(intel_dp, true);
> +
> return true;
> }
>
> --
> 2.26.2
>
Re: [PATCH 1/3] Bluetooth: Add new quirk for broken local ext features max_page
On Sun, Jul 12, 2020 at 11:28 PM Marcel Holtmann wrote: Hi Marcel, > maybe just the read sync train params command is broken? Can you change the > init code and not send it and see if the rest of the init phase proceeds. I > would rather have the secure connections actually tested before dismissing it > altogether. I don't think that I have any devices that support secure connections to test, I've got only a bluetooth mouse and headphones, both are from the 2.0 era. FWIW unofficial recommendation from Realtek to Pine64 was to avoid using any 4.1+ features on this chip. Unfortunately I don't have any contacts with Realtek, so I can't confirm that. > Mind you, there were broken Broadcom implementation of connectionless slave > broadcast as well. Maybe this is similar. I'd prefer to stick to what works unless there's some comprehensive test that can figure out what's broken. Regards, Vasily
[PATCH v4] ALSA: line6: add hw monitor volume control for POD HD500
Add hw monitor volume control for POD HD500. The same change may
work for HD500X but I don't have it to test.
Signed-off-by: Vasily Khoruzhick
---
v4: add NULL check for kmalloc-ed buffer
v3: - use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL
- use GFP_KERNEL instead of GFP_ATOMIC for allocating a message
- use lower case for float lookup table
v2: clamp volume value to [0, ARRAY_SIZE() -1] in
podhd_set_monitor_level()
sound/usb/line6/driver.c | 3 +-
sound/usb/line6/driver.h | 4 ++
sound/usb/line6/podhd.c | 127 ++-
3 files changed, 132 insertions(+), 2 deletions(-)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 7629116f570e..3e07251b80e3 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -97,7 +97,7 @@ static void line6_stop_listen(struct usb_line6 *line6)
/*
Send raw message in pieces of wMaxPacketSize bytes.
*/
-static int line6_send_raw_message(struct usb_line6 *line6, const char *buffer,
+int line6_send_raw_message(struct usb_line6 *line6, const char *buffer,
int size)
{
int i, done = 0;
@@ -132,6 +132,7 @@ static int line6_send_raw_message(struct usb_line6 *line6,
const char *buffer,
return done;
}
+EXPORT_SYMBOL_GPL(line6_send_raw_message);
/*
Notification of completion of asynchronous request transmission.
diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
index 1a4e3700c80c..62c686bed0ca 100644
--- a/sound/usb/line6/driver.h
+++ b/sound/usb/line6/driver.h
@@ -108,6 +108,8 @@ enum {
LINE6_CAP_CONTROL_MIDI = 1 << 4,
/* device provides low-level information */
LINE6_CAP_CONTROL_INFO = 1 << 5,
+ /* device provides hardware monitoring volume control */
+ LINE6_CAP_HWMON_CTL = 1 << 6,
};
/*
@@ -185,6 +187,8 @@ extern int line6_read_data(struct usb_line6 *line6,
unsigned address,
void *data, unsigned datalen);
extern int line6_read_serial_number(struct usb_line6 *line6,
u32 *serial_number);
+extern int line6_send_raw_message(struct usb_line6 *line6,
+ const char *buffer, int size);
extern int line6_send_raw_message_async(struct usb_line6 *line6,
const char *buffer, int size);
extern int line6_send_sysex_message(struct usb_line6 *line6,
diff --git a/sound/usb/line6/podhd.c b/sound/usb/line6/podhd.c
index e39dc85c355a..1557483ec657 100644
--- a/sound/usb/line6/podhd.c
+++ b/sound/usb/line6/podhd.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include "driver.h"
@@ -37,6 +38,9 @@ struct usb_line6_podhd {
/* Firmware version */
int firmware_version;
+
+ /* Monitor level */
+ int monitor_level;
};
#define line6_to_podhd(x) container_of(x, struct usb_line6_podhd, line6)
@@ -250,6 +254,118 @@ static void podhd_disconnect(struct usb_line6 *line6)
}
}
+static const unsigned int float_zero_to_one_lookup[] = {
+0x, 0x3c23d70a, 0x3ca3d70a, 0x3cf5c28f, 0x3d23d70a, 0x3d4d,
+0x3d75c28f, 0x3d8f5c29, 0x3da3d70a, 0x3db851ec, 0x3dcd, 0x3de147ae,
+0x3df5c28f, 0x3e051eb8, 0x3e0f5c29, 0x3e1a, 0x3e23d70a, 0x3e2e147b,
+0x3e3851ec, 0x3e428f5c, 0x3e4d, 0x3e570a3d, 0x3e6147ae, 0x3e6b851f,
+0x3e75c28f, 0x3e80, 0x3e851eb8, 0x3e8a3d71, 0x3e8f5c29, 0x3e947ae1,
+0x3e9a, 0x3e9eb852, 0x3ea3d70a, 0x3ea8f5c3, 0x3eae147b, 0x3eb3,
+0x3eb851ec, 0x3ebd70a4, 0x3ec28f5c, 0x3ec7ae14, 0x3ecd, 0x3ed1eb85,
+0x3ed70a3d, 0x3edc28f6, 0x3ee147ae, 0x3ee6, 0x3eeb851f, 0x3ef0a3d7,
+0x3ef5c28f, 0x3efae148, 0x3f00, 0x3f028f5c, 0x3f051eb8, 0x3f07ae14,
+0x3f0a3d71, 0x3f0d, 0x3f0f5c29, 0x3f11eb85, 0x3f147ae1, 0x3f170a3d,
+0x3f1a, 0x3f1c28f6, 0x3f1eb852, 0x3f2147ae, 0x3f23d70a, 0x3f26,
+0x3f28f5c3, 0x3f2b851f, 0x3f2e147b, 0x3f30a3d7, 0x3f33, 0x3f35c28f,
+0x3f3851ec, 0x3f3ae148, 0x3f3d70a4, 0x3f40, 0x3f428f5c, 0x3f451eb8,
+0x3f47ae14, 0x3f4a3d71, 0x3f4d, 0x3f4f5c29, 0x3f51eb85, 0x3f547ae1,
+0x3f570a3d, 0x3f5a, 0x3f5c28f6, 0x3f5eb852, 0x3f6147ae, 0x3f63d70a,
+0x3f66, 0x3f68f5c3, 0x3f6b851f, 0x3f6e147b, 0x3f70a3d7, 0x3f73,
+0x3f75c28f, 0x3f7851ec, 0x3f7ae148, 0x3f7d70a4, 0x3f80
+};
+
+static void podhd_set_monitor_level(struct usb_line6_podhd *podhd, int value)
+{
+ unsigned int fl;
+ static const unsigned char msg[16] = {
+ /* Chunk is 0xc bytes (without first word) */
+ 0x0c, 0x00,
+ /* First chunk in the message */
+ 0x01, 0x00,
+ /* Message size is 2 4-byte words */
+ 0x02, 0x00,
+ /* Unknown */
+ 0x04, 0x41,
+ /* Unknown */
+ 0x04, 0x00, 0x13, 0x00,
+ /* Volume, LE float32, 0.0 - 1.0 */
+ 0x00, 0x00, 0x00, 0x00
+
[PATCH v3] ALSA: line6: add hw monitor volume control for POD HD500
Add hw monitor volume control for POD HD500. The same change may
work for HD500X but I don't have it to test.
Signed-off-by: Vasily Khoruzhick
---
v3: - use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL
- use GFP_KERNEL instead of GFP_ATOMIC for allocating a message
- use lower case for float lookup table
v2: clamp volume value to [0, ARRAY_SIZE() -1] in
podhd_set_monitor_level()
sound/usb/line6/driver.c | 3 +-
sound/usb/line6/driver.h | 4 ++
sound/usb/line6/podhd.c | 124 ++-
3 files changed, 129 insertions(+), 2 deletions(-)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 7629116f570e..3e07251b80e3 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -97,7 +97,7 @@ static void line6_stop_listen(struct usb_line6 *line6)
/*
Send raw message in pieces of wMaxPacketSize bytes.
*/
-static int line6_send_raw_message(struct usb_line6 *line6, const char *buffer,
+int line6_send_raw_message(struct usb_line6 *line6, const char *buffer,
int size)
{
int i, done = 0;
@@ -132,6 +132,7 @@ static int line6_send_raw_message(struct usb_line6 *line6,
const char *buffer,
return done;
}
+EXPORT_SYMBOL_GPL(line6_send_raw_message);
/*
Notification of completion of asynchronous request transmission.
diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
index 1a4e3700c80c..62c686bed0ca 100644
--- a/sound/usb/line6/driver.h
+++ b/sound/usb/line6/driver.h
@@ -108,6 +108,8 @@ enum {
LINE6_CAP_CONTROL_MIDI = 1 << 4,
/* device provides low-level information */
LINE6_CAP_CONTROL_INFO = 1 << 5,
+ /* device provides hardware monitoring volume control */
+ LINE6_CAP_HWMON_CTL = 1 << 6,
};
/*
@@ -185,6 +187,8 @@ extern int line6_read_data(struct usb_line6 *line6,
unsigned address,
void *data, unsigned datalen);
extern int line6_read_serial_number(struct usb_line6 *line6,
u32 *serial_number);
+extern int line6_send_raw_message(struct usb_line6 *line6,
+ const char *buffer, int size);
extern int line6_send_raw_message_async(struct usb_line6 *line6,
const char *buffer, int size);
extern int line6_send_sysex_message(struct usb_line6 *line6,
diff --git a/sound/usb/line6/podhd.c b/sound/usb/line6/podhd.c
index e39dc85c355a..0410d256aa50 100644
--- a/sound/usb/line6/podhd.c
+++ b/sound/usb/line6/podhd.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include "driver.h"
@@ -37,6 +38,9 @@ struct usb_line6_podhd {
/* Firmware version */
int firmware_version;
+
+ /* Monitor level */
+ int monitor_level;
};
#define line6_to_podhd(x) container_of(x, struct usb_line6_podhd, line6)
@@ -250,6 +254,115 @@ static void podhd_disconnect(struct usb_line6 *line6)
}
}
+static const unsigned int float_zero_to_one_lookup[] = {
+0x, 0x3c23d70a, 0x3ca3d70a, 0x3cf5c28f, 0x3d23d70a, 0x3d4d,
+0x3d75c28f, 0x3d8f5c29, 0x3da3d70a, 0x3db851ec, 0x3dcd, 0x3de147ae,
+0x3df5c28f, 0x3e051eb8, 0x3e0f5c29, 0x3e1a, 0x3e23d70a, 0x3e2e147b,
+0x3e3851ec, 0x3e428f5c, 0x3e4d, 0x3e570a3d, 0x3e6147ae, 0x3e6b851f,
+0x3e75c28f, 0x3e80, 0x3e851eb8, 0x3e8a3d71, 0x3e8f5c29, 0x3e947ae1,
+0x3e9a, 0x3e9eb852, 0x3ea3d70a, 0x3ea8f5c3, 0x3eae147b, 0x3eb3,
+0x3eb851ec, 0x3ebd70a4, 0x3ec28f5c, 0x3ec7ae14, 0x3ecd, 0x3ed1eb85,
+0x3ed70a3d, 0x3edc28f6, 0x3ee147ae, 0x3ee6, 0x3eeb851f, 0x3ef0a3d7,
+0x3ef5c28f, 0x3efae148, 0x3f00, 0x3f028f5c, 0x3f051eb8, 0x3f07ae14,
+0x3f0a3d71, 0x3f0d, 0x3f0f5c29, 0x3f11eb85, 0x3f147ae1, 0x3f170a3d,
+0x3f1a, 0x3f1c28f6, 0x3f1eb852, 0x3f2147ae, 0x3f23d70a, 0x3f26,
+0x3f28f5c3, 0x3f2b851f, 0x3f2e147b, 0x3f30a3d7, 0x3f33, 0x3f35c28f,
+0x3f3851ec, 0x3f3ae148, 0x3f3d70a4, 0x3f40, 0x3f428f5c, 0x3f451eb8,
+0x3f47ae14, 0x3f4a3d71, 0x3f4d, 0x3f4f5c29, 0x3f51eb85, 0x3f547ae1,
+0x3f570a3d, 0x3f5a, 0x3f5c28f6, 0x3f5eb852, 0x3f6147ae, 0x3f63d70a,
+0x3f66, 0x3f68f5c3, 0x3f6b851f, 0x3f6e147b, 0x3f70a3d7, 0x3f73,
+0x3f75c28f, 0x3f7851ec, 0x3f7ae148, 0x3f7d70a4, 0x3f80
+};
+
+static void podhd_set_monitor_level(struct usb_line6_podhd *podhd, int value)
+{
+ unsigned int fl;
+ static const unsigned char msg[16] = {
+ /* Chunk is 0xc bytes (without first word) */
+ 0x0c, 0x00,
+ /* First chunk in the message */
+ 0x01, 0x00,
+ /* Message size is 2 4-byte words */
+ 0x02, 0x00,
+ /* Unknown */
+ 0x04, 0x41,
+ /* Unknown */
+ 0x04, 0x00, 0x13, 0x00,
+ /* Volume, LE float32, 0.0 - 1.0 */
+ 0x00, 0x00, 0x00, 0x00
+ };
+ unsigned char *buf;
+
+
Re: [PATCH 3/3] arm64: allwinner: a64: enable Bluetooth On Pinebook
On Mon, Jul 6, 2020 at 4:47 AM Maxime Ripard wrote:
>
> Hi,
>
> On Sun, Jul 05, 2020 at 12:51:10PM -0700, Vasily Khoruzhick wrote:
> > Pinebook has an RTL8723CS WiFi + BT chip, BT is connected to UART1
> > and uses PL5 as device wake GPIO, PL6 as host wake GPIO the I2C
> > controlling signals are connected to R_I2C bus.
> >
> > Enable it in the device tree.
> >
> > Signed-off-by: Vasily Khoruzhick
> > ---
> > .../arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > index 64b1c54f87c0..e63ff271be4e 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > @@ -408,6 +408,18 @@ {
> > status = "okay";
> > };
> >
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pins>, <_rts_cts_pins>;
> > + status = "okay";
>
> You probably need uart-has-rtscts here
Will add in v2
> > +
> > + bluetooth {
> > + compatible = "realtek,rtl8723cs-bt";
> > + device-wake-gpios = <_pio 0 5 GPIO_ACTIVE_LOW>; /* PL5 */
> > + host-wake-gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
> > + };
>
> And max-speed I guess?
There's no max-speed in the schema for this bluetooth controller.
Moreover it reads uart settings from firmware config. See
btrtl_get_uart_settings() in drivers/bluetooth/btrtl.c
> Maxime
> >
Re: [PATCH 1/3] Bluetooth: Add new quirk for broken local ext features max_page
On Tue, Jul 7, 2020 at 9:03 AM Marcel Holtmann wrote: > > Hi Vasily, > > > Some adapters (e.g. RTL8723CS) advertise that they have more than > > 2 pages for local ext features, but they don't support any features > > declared in these pages. RTL8723CS reports max_page = 2 and declares > > support for sync train and secure connection, but it responds with > > either garbage or with error in status on corresponding commands. > > please send the btmon for this so I can see what the controller is responding. Here is relevant part: < HCI Command: Read Local Extend.. (0x04|0x0004) plen 1 #228 [hci0] 6.889869 Page: 2 > HCI Event: Command Complete (0x0e) plen 14 #229 [hci0] 6.890487 Read Local Extended Features (0x04|0x0004) ncmd 2 Status: Success (0x00) Page: 2/2 Features: 0x5f 0x03 0x00 0x00 0x00 0x00 0x00 0x00 Connectionless Slave Broadcast - Master Connectionless Slave Broadcast - Slave Synchronization Train Synchronization Scan Inquiry Response Notification Event Coarse Clock Adjustment Secure Connections (Controller Support) Ping < HCI Command: Delete Stored Lin.. (0x03|0x0012) plen 7 #230 [hci0] 6.890559 Address: 00:00:00:00:00:00 (OUI 00-00-00) Delete all: 0x01 > HCI Event: Command Complete (0x0e) plen 6 #231 [hci0] 6.891170 Delete Stored Link Key (0x03|0x0012) ncmd 2 Status: Success (0x00) Num keys: 0 < HCI Command: Read Synchronizat.. (0x03|0x0077) plen 0 #232 [hci0] 6.891199 > HCI Event: Command Complete (0x0e) plen 9 #233 [hci0] 6.891788 Read Synchronization Train Parameters (0x03|0x0077) ncmd 2 invalid packet size 01 ac bd 11 80 80.. = Close Index: 00:E0:4C:23:99:87 [hci0] 6.891832 hci0 registration stops here and bluetoothctl doesn't even see the controller. > Regards > > Marcel >
Re: [PATCH 2/3] Bluetooth: btrtl: add support for the RTL8723CS
On Tue, Jul 7, 2020 at 9:01 AM Marcel Holtmann wrote:
>
> Hi Vasily,
>
> > The Realtek RTL8723CS is SDIO WiFi chip. It also contains a Bluetooth
> > module which is connected via UART to the host.
> >
> > It shares lmp subversion with 8703B, so Realtek's userspace
> > initialization tool (rtk_hciattach) differentiates varieties of RTL8723CS
> > (CG, VF, XX) with RTL8703B using vendor's command to read chip type.
> >
> > Also this chip declares support for some features it doesn't support
> > so add a quirk to indicate that these features are broken.
> >
> > Signed-off-by: Vasily Khoruzhick
> > ---
> > drivers/bluetooth/btrtl.c | 128 -
> > drivers/bluetooth/btrtl.h | 12
> > drivers/bluetooth/hci_h5.c | 6 ++
> > 3 files changed, 143 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
> > index 3a9afc905f24..8c7b35abe492 100644
> > --- a/drivers/bluetooth/btrtl.c
> > +++ b/drivers/bluetooth/btrtl.c
> > @@ -17,8 +17,12 @@
> >
> > #define VERSION "0.1"
> >
> > +#define RTL_CHIP_8723CS_CG 3
> > +#define RTL_CHIP_8723CS_VF 4
> > +#define RTL_CHIP_8723CS_XX 5
> > #define RTL_EPATCH_SIGNATURE "Realtech"
> > #define RTL_ROM_LMP_3499 0x3499
> > +#define RTL_ROM_LMP_8703B0x8703
> > #define RTL_ROM_LMP_8723A 0x1200
> > #define RTL_ROM_LMP_8723B 0x8723
> > #define RTL_ROM_LMP_8723D 0x8873
> > @@ -31,6 +35,7 @@
> > #define IC_MATCH_FL_HCIREV(1 << 1)
> > #define IC_MATCH_FL_HCIVER(1 << 2)
> > #define IC_MATCH_FL_HCIBUS(1 << 3)
> > +#define IC_MATCH_FL_CHIP_TYPE(1 << 4)
> > #define IC_INFO(lmps, hcir) \
> > .match_flags = IC_MATCH_FL_LMPSUBV | IC_MATCH_FL_HCIREV, \
> > .lmp_subver = (lmps), \
> > @@ -42,6 +47,7 @@ struct id_table {
> > __u16 hci_rev;
> > __u8 hci_ver;
> > __u8 hci_bus;
> > + __u8 chip_type;
> > bool config_needed;
> > bool has_rom_version;
> > char *fw_name;
> > @@ -89,6 +95,39 @@ static const struct id_table ic_id_table[] = {
> > .fw_name = "rtl_bt/rtl8723b_fw.bin",
> > .cfg_name = "rtl_bt/rtl8723b_config" },
> >
> > + /* 8723CS-CG */
> > + { .match_flags = IC_MATCH_FL_LMPSUBV | IC_MATCH_FL_CHIP_TYPE |
> > + IC_MATCH_FL_HCIBUS,
> > + .lmp_subver = RTL_ROM_LMP_8703B,
> > + .chip_type = RTL_CHIP_8723CS_CG,
> > + .hci_bus = HCI_UART,
> > + .config_needed = true,
> > + .has_rom_version = true,
> > + .fw_name = "rtl_bt/rtl8723cs_cg_fw.bin",
> > + .cfg_name = "rtl_bt/rtl8723cs_cg_config" },
> > +
> > + /* 8723CS-VF */
> > + { .match_flags = IC_MATCH_FL_LMPSUBV | IC_MATCH_FL_CHIP_TYPE |
> > + IC_MATCH_FL_HCIBUS,
> > + .lmp_subver = RTL_ROM_LMP_8703B,
> > + .chip_type = RTL_CHIP_8723CS_VF,
> > + .hci_bus = HCI_UART,
> > + .config_needed = true,
> > + .has_rom_version = true,
> > + .fw_name = "rtl_bt/rtl8723cs_vf_fw.bin",
> > + .cfg_name = "rtl_bt/rtl8723cs_vf_config" },
> > +
> > + /* 8723CS-XX */
> > + { .match_flags = IC_MATCH_FL_LMPSUBV | IC_MATCH_FL_CHIP_TYPE |
> > + IC_MATCH_FL_HCIBUS,
> > + .lmp_subver = RTL_ROM_LMP_8703B,
> > + .chip_type = RTL_CHIP_8723CS_XX,
> > + .hci_bus = HCI_UART,
> > + .config_needed = true,
> > + .has_rom_version = true,
> > + .fw_name = "rtl_bt/rtl8723cs_xx_fw.bin",
> > + .cfg_name = "rtl_bt/rtl8723cs_xx_config" },
> > +
> > /* 8723D */
> > { IC_INFO(RTL_ROM_LMP_8723B, 0xd),
> > .config_needed = true,
> > @@ -171,7 +210,8 @@ static const struct id_table ic_id_table[] = {
> > };
> >
> > static const struct id_table *btrtl_match_ic(u16 lmp_subver, u16 hci_rev,
> > - u8 hci_ver, u8 hci_bus)
> > + u8 hci_ver, u8 hci_bus,
> > + u8 chip_type)
> > {
> > int i;
> >
> > @@ -188,6 +228,9 @@ static const struct id_table *btrtl_match_ic(u16
> > lmp_subver, u16 hci_rev,
> > if ((ic_id_table[i].match_flags & IC_MATCH_FL_HCIBUS) &&
> &g
[PATCH 1/3] Bluetooth: Add new quirk for broken local ext features max_page
Some adapters (e.g. RTL8723CS) advertise that they have more than
2 pages for local ext features, but they don't support any features
declared in these pages. RTL8723CS reports max_page = 2 and declares
support for sync train and secure connection, but it responds with
either garbage or with error in status on corresponding commands.
Signed-off-by: Vasily Khoruzhick
---
include/net/bluetooth/hci.h | 7 +++
net/bluetooth/hci_event.c | 4 +++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 16ab6ce87883..8e4c16210d18 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -227,6 +227,13 @@ enum {
* supported.
*/
HCI_QUIRK_VALID_LE_STATES,
+
+ /* When this quirk is set, max_page for local extended features
+* is set to 1, even if controller reports higher number. Some
+* controllers (e.g. RTL8723CS) report more pages, but they
+* don't actually support features declared there.
+*/
+ HCI_QUIRK_BROKEN_LOCAL_EXT_FTR_MAX_PAGE,
};
/* HCI device flags */
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index cfeaee347db3..df3232828978 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -700,7 +700,9 @@ static void hci_cc_read_local_ext_features(struct hci_dev
*hdev,
if (rp->status)
return;
- if (hdev->max_page < rp->max_page)
+ if (!test_bit(HCI_QUIRK_BROKEN_LOCAL_EXT_FTR_MAX_PAGE,
+ >quirks) &&
+ hdev->max_page < rp->max_page)
hdev->max_page = rp->max_page;
if (rp->page < HCI_MAX_PAGES)
--
2.27.0
[PATCH 0/3] arm64: allwinner: a64: add bluetooth support for Pinebook
Pinebook uses RTL8723CS for WiFi and bluetooth. Unfortunately RTL8723CS has broken BT-4.1 support, so it requires a quirk. Add a quirk, wire up 8723CS support in btrtl and enable bluetooth in Pinebook dts. Vasily Khoruzhick (3): Bluetooth: Add new quirk for broken local ext features max_page Bluetooth: btrtl: add support for the RTL8723CS arm64: allwinner: a64: enable Bluetooth On Pinebook .../dts/allwinner/sun50i-a64-pinebook.dts | 12 ++ drivers/bluetooth/btrtl.c | 128 +- drivers/bluetooth/btrtl.h | 12 ++ drivers/bluetooth/hci_h5.c| 6 + include/net/bluetooth/hci.h | 7 + net/bluetooth/hci_event.c | 4 +- 6 files changed, 165 insertions(+), 4 deletions(-) -- 2.27.0
[PATCH 2/3] Bluetooth: btrtl: add support for the RTL8723CS
The Realtek RTL8723CS is SDIO WiFi chip. It also contains a Bluetooth
module which is connected via UART to the host.
It shares lmp subversion with 8703B, so Realtek's userspace
initialization tool (rtk_hciattach) differentiates varieties of RTL8723CS
(CG, VF, XX) with RTL8703B using vendor's command to read chip type.
Also this chip declares support for some features it doesn't support
so add a quirk to indicate that these features are broken.
Signed-off-by: Vasily Khoruzhick
---
drivers/bluetooth/btrtl.c | 128 -
drivers/bluetooth/btrtl.h | 12
drivers/bluetooth/hci_h5.c | 6 ++
3 files changed, 143 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
index 3a9afc905f24..8c7b35abe492 100644
--- a/drivers/bluetooth/btrtl.c
+++ b/drivers/bluetooth/btrtl.c
@@ -17,8 +17,12 @@
#define VERSION "0.1"
+#define RTL_CHIP_8723CS_CG 3
+#define RTL_CHIP_8723CS_VF 4
+#define RTL_CHIP_8723CS_XX 5
#define RTL_EPATCH_SIGNATURE "Realtech"
#define RTL_ROM_LMP_3499 0x3499
+#define RTL_ROM_LMP_8703B 0x8703
#define RTL_ROM_LMP_8723A 0x1200
#define RTL_ROM_LMP_8723B 0x8723
#define RTL_ROM_LMP_8723D 0x8873
@@ -31,6 +35,7 @@
#define IC_MATCH_FL_HCIREV (1 << 1)
#define IC_MATCH_FL_HCIVER (1 << 2)
#define IC_MATCH_FL_HCIBUS (1 << 3)
+#define IC_MATCH_FL_CHIP_TYPE (1 << 4)
#define IC_INFO(lmps, hcir) \
.match_flags = IC_MATCH_FL_LMPSUBV | IC_MATCH_FL_HCIREV, \
.lmp_subver = (lmps), \
@@ -42,6 +47,7 @@ struct id_table {
__u16 hci_rev;
__u8 hci_ver;
__u8 hci_bus;
+ __u8 chip_type;
bool config_needed;
bool has_rom_version;
char *fw_name;
@@ -89,6 +95,39 @@ static const struct id_table ic_id_table[] = {
.fw_name = "rtl_bt/rtl8723b_fw.bin",
.cfg_name = "rtl_bt/rtl8723b_config" },
+ /* 8723CS-CG */
+ { .match_flags = IC_MATCH_FL_LMPSUBV | IC_MATCH_FL_CHIP_TYPE |
+IC_MATCH_FL_HCIBUS,
+ .lmp_subver = RTL_ROM_LMP_8703B,
+ .chip_type = RTL_CHIP_8723CS_CG,
+ .hci_bus = HCI_UART,
+ .config_needed = true,
+ .has_rom_version = true,
+ .fw_name = "rtl_bt/rtl8723cs_cg_fw.bin",
+ .cfg_name = "rtl_bt/rtl8723cs_cg_config" },
+
+ /* 8723CS-VF */
+ { .match_flags = IC_MATCH_FL_LMPSUBV | IC_MATCH_FL_CHIP_TYPE |
+IC_MATCH_FL_HCIBUS,
+ .lmp_subver = RTL_ROM_LMP_8703B,
+ .chip_type = RTL_CHIP_8723CS_VF,
+ .hci_bus = HCI_UART,
+ .config_needed = true,
+ .has_rom_version = true,
+ .fw_name = "rtl_bt/rtl8723cs_vf_fw.bin",
+ .cfg_name = "rtl_bt/rtl8723cs_vf_config" },
+
+ /* 8723CS-XX */
+ { .match_flags = IC_MATCH_FL_LMPSUBV | IC_MATCH_FL_CHIP_TYPE |
+IC_MATCH_FL_HCIBUS,
+ .lmp_subver = RTL_ROM_LMP_8703B,
+ .chip_type = RTL_CHIP_8723CS_XX,
+ .hci_bus = HCI_UART,
+ .config_needed = true,
+ .has_rom_version = true,
+ .fw_name = "rtl_bt/rtl8723cs_xx_fw.bin",
+ .cfg_name = "rtl_bt/rtl8723cs_xx_config" },
+
/* 8723D */
{ IC_INFO(RTL_ROM_LMP_8723B, 0xd),
.config_needed = true,
@@ -171,7 +210,8 @@ static const struct id_table ic_id_table[] = {
};
static const struct id_table *btrtl_match_ic(u16 lmp_subver, u16 hci_rev,
-u8 hci_ver, u8 hci_bus)
+u8 hci_ver, u8 hci_bus,
+u8 chip_type)
{
int i;
@@ -188,6 +228,9 @@ static const struct id_table *btrtl_match_ic(u16
lmp_subver, u16 hci_rev,
if ((ic_id_table[i].match_flags & IC_MATCH_FL_HCIBUS) &&
(ic_id_table[i].hci_bus != hci_bus))
continue;
+ if ((ic_id_table[i].match_flags & IC_MATCH_FL_CHIP_TYPE) &&
+ (ic_id_table[i].chip_type != chip_type))
+ continue;
break;
}
@@ -270,6 +313,7 @@ static int rtlbt_parse_firmware(struct hci_dev *hdev,
{ RTL_ROM_LMP_8723B, 1 },
{ RTL_ROM_LMP_8821A, 2 },
{ RTL_ROM_LMP_8761A, 3 },
+ { RTL_ROM_LMP_8703B, 7 },
{ RTL_ROM_LMP_8822B, 8 },
{ RTL_ROM_LMP_8723B, 9 }, /* 8723D */
{ RTL_ROM_LMP_8821A, 10 }, /* 8821C */
@@ -545,6 +589,48 @@ static int btrtl_setup_rtl8723b(struct hci_dev *hdev,
return ret;
}
+static bool rtl_has_chip_type(u16 lmp_subver)
+{
+ switch (lmp_subver) {
+ case RTL_ROM_LMP_8703B:
+ return true;
+ default:
+
[PATCH 3/3] arm64: allwinner: a64: enable Bluetooth On Pinebook
Pinebook has an RTL8723CS WiFi + BT chip, BT is connected to UART1
and uses PL5 as device wake GPIO, PL6 as host wake GPIO the I2C
controlling signals are connected to R_I2C bus.
Enable it in the device tree.
Signed-off-by: Vasily Khoruzhick
---
.../arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
index 64b1c54f87c0..e63ff271be4e 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
@@ -408,6 +408,18 @@ {
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>, <_rts_cts_pins>;
+ status = "okay";
+
+ bluetooth {
+ compatible = "realtek,rtl8723cs-bt";
+ device-wake-gpios = <_pio 0 5 GPIO_ACTIVE_LOW>; /* PL5 */
+ host-wake-gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
+ };
+};
+
_otg {
dr_mode = "host";
};
--
2.27.0
Re: [PATCH v2] ALSA: line6: add hw monitor volume control for POD HD500
On Sat, May 23, 2020 at 11:59 PM Takashi Iwai wrote:
> Thanks for the patch.
> The basic implementation looks good, but I see a few issues.
> > +EXPORT_SYMBOL(line6_send_raw_message);
>
> Let's use EXPORT_SYMBOL_GPL() instead.
Sure, will do.
> > +static const unsigned int float_zero_to_one_lookup[] = {
> > +0x, 0x3C23D70A, 0x3CA3D70A, 0x3CF5C28F, 0x3D23D70A, 0x3D4D,
> > +0x3D75C28F, 0x3D8F5C29, 0x3DA3D70A, 0x3DB851EC, 0x3DCD, 0x3DE147AE,
> > +0x3DF5C28F, 0x3E051EB8, 0x3E0F5C29, 0x3E1A, 0x3E23D70A, 0x3E2E147B,
> > +0x3E3851EC, 0x3E428F5C, 0x3E4D, 0x3E570A3D, 0x3E6147AE, 0x3E6B851F,
> > +0x3E75C28F, 0x3E80, 0x3E851EB8, 0x3E8A3D71, 0x3E8F5C29, 0x3E947AE1,
> > +0x3E9A, 0x3E9EB852, 0x3EA3D70A, 0x3EA8F5C3, 0x3EAE147B, 0x3EB3,
> > +0x3EB851EC, 0x3EBD70A4, 0x3EC28F5C, 0x3EC7AE14, 0x3ECD, 0x3ED1EB85,
> > +0x3ED70A3D, 0x3EDC28F6, 0x3EE147AE, 0x3EE6, 0x3EEB851F, 0x3EF0A3D7,
> > +0x3EF5C28F, 0x3EFAE148, 0x3F00, 0x3F028F5C, 0x3F051EB8, 0x3F07AE14,
> > +0x3F0A3D71, 0x3F0D, 0x3F0F5C29, 0x3F11EB85, 0x3F147AE1, 0x3F170A3D,
> > +0x3F1A, 0x3F1C28F6, 0x3F1EB852, 0x3F2147AE, 0x3F23D70A, 0x3F26,
> > +0x3F28F5C3, 0x3F2B851F, 0x3F2E147B, 0x3F30A3D7, 0x3F33, 0x3F35C28F,
> > +0x3F3851EC, 0x3F3AE148, 0x3F3D70A4, 0x3F40, 0x3F428F5C, 0x3F451EB8,
> > +0x3F47AE14, 0x3F4A3D71, 0x3F4D, 0x3F4F5C29, 0x3F51EB85, 0x3F547AE1,
> > +0x3F570A3D, 0x3F5A, 0x3F5C28F6, 0x3F5EB852, 0x3F6147AE, 0x3F63D70A,
> > +0x3F66, 0x3F68F5C3, 0x3F6B851F, 0x3F6E147B, 0x3F70A3D7, 0x3F73,
> > +0x3F75C28F, 0x3F7851EC, 0x3F7AE148, 0x3F7D70A4, 0x3F80
>
> Just nitpick: better to align with lower hex letters (a-f).
Sorry, I don't really understand what you meant here. Could you elaborate?
> > + buf = kmalloc(sizeof(msg), GFP_ATOMIC);
>
> Is this function called from the irq context like the urb callback?
> I saw that it's called from the mixer put callback, and it's in the
> normal sleepable context, hence GFP_KERNEL can be used safely.
It's also called from podhd_init() to set initial value but I assume
it can sleep there. I'll change it to GFP_KERNEL.
Thanks for review!
Regards,
Vasily
[PATCH v2] ALSA: line6: add hw monitor volume control for POD HD500
Add hw monitor volume control for POD HD500. The same change may
work for HD500X but I don't have it to test.
Signed-off-by: Vasily Khoruzhick
---
v2: clamp volume value to [0, ARRAY_SIZE() -1] in
podhd_set_monitor_level()
sound/usb/line6/driver.c | 3 +-
sound/usb/line6/driver.h | 4 ++
sound/usb/line6/podhd.c | 124 ++-
3 files changed, 129 insertions(+), 2 deletions(-)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 7629116f570e..597a36c0a51d 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -97,7 +97,7 @@ static void line6_stop_listen(struct usb_line6 *line6)
/*
Send raw message in pieces of wMaxPacketSize bytes.
*/
-static int line6_send_raw_message(struct usb_line6 *line6, const char *buffer,
+int line6_send_raw_message(struct usb_line6 *line6, const char *buffer,
int size)
{
int i, done = 0;
@@ -132,6 +132,7 @@ static int line6_send_raw_message(struct usb_line6 *line6,
const char *buffer,
return done;
}
+EXPORT_SYMBOL(line6_send_raw_message);
/*
Notification of completion of asynchronous request transmission.
diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
index 1a4e3700c80c..62c686bed0ca 100644
--- a/sound/usb/line6/driver.h
+++ b/sound/usb/line6/driver.h
@@ -108,6 +108,8 @@ enum {
LINE6_CAP_CONTROL_MIDI = 1 << 4,
/* device provides low-level information */
LINE6_CAP_CONTROL_INFO = 1 << 5,
+ /* device provides hardware monitoring volume control */
+ LINE6_CAP_HWMON_CTL = 1 << 6,
};
/*
@@ -185,6 +187,8 @@ extern int line6_read_data(struct usb_line6 *line6,
unsigned address,
void *data, unsigned datalen);
extern int line6_read_serial_number(struct usb_line6 *line6,
u32 *serial_number);
+extern int line6_send_raw_message(struct usb_line6 *line6,
+ const char *buffer, int size);
extern int line6_send_raw_message_async(struct usb_line6 *line6,
const char *buffer, int size);
extern int line6_send_sysex_message(struct usb_line6 *line6,
diff --git a/sound/usb/line6/podhd.c b/sound/usb/line6/podhd.c
index e39dc85c355a..7cc2f1540c7c 100644
--- a/sound/usb/line6/podhd.c
+++ b/sound/usb/line6/podhd.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include "driver.h"
@@ -37,6 +38,9 @@ struct usb_line6_podhd {
/* Firmware version */
int firmware_version;
+
+ /* Monitor level */
+ int monitor_level;
};
#define line6_to_podhd(x) container_of(x, struct usb_line6_podhd, line6)
@@ -250,6 +254,115 @@ static void podhd_disconnect(struct usb_line6 *line6)
}
}
+static const unsigned int float_zero_to_one_lookup[] = {
+0x, 0x3C23D70A, 0x3CA3D70A, 0x3CF5C28F, 0x3D23D70A, 0x3D4D,
+0x3D75C28F, 0x3D8F5C29, 0x3DA3D70A, 0x3DB851EC, 0x3DCD, 0x3DE147AE,
+0x3DF5C28F, 0x3E051EB8, 0x3E0F5C29, 0x3E1A, 0x3E23D70A, 0x3E2E147B,
+0x3E3851EC, 0x3E428F5C, 0x3E4D, 0x3E570A3D, 0x3E6147AE, 0x3E6B851F,
+0x3E75C28F, 0x3E80, 0x3E851EB8, 0x3E8A3D71, 0x3E8F5C29, 0x3E947AE1,
+0x3E9A, 0x3E9EB852, 0x3EA3D70A, 0x3EA8F5C3, 0x3EAE147B, 0x3EB3,
+0x3EB851EC, 0x3EBD70A4, 0x3EC28F5C, 0x3EC7AE14, 0x3ECD, 0x3ED1EB85,
+0x3ED70A3D, 0x3EDC28F6, 0x3EE147AE, 0x3EE6, 0x3EEB851F, 0x3EF0A3D7,
+0x3EF5C28F, 0x3EFAE148, 0x3F00, 0x3F028F5C, 0x3F051EB8, 0x3F07AE14,
+0x3F0A3D71, 0x3F0D, 0x3F0F5C29, 0x3F11EB85, 0x3F147AE1, 0x3F170A3D,
+0x3F1A, 0x3F1C28F6, 0x3F1EB852, 0x3F2147AE, 0x3F23D70A, 0x3F26,
+0x3F28F5C3, 0x3F2B851F, 0x3F2E147B, 0x3F30A3D7, 0x3F33, 0x3F35C28F,
+0x3F3851EC, 0x3F3AE148, 0x3F3D70A4, 0x3F40, 0x3F428F5C, 0x3F451EB8,
+0x3F47AE14, 0x3F4A3D71, 0x3F4D, 0x3F4F5C29, 0x3F51EB85, 0x3F547AE1,
+0x3F570A3D, 0x3F5A, 0x3F5C28F6, 0x3F5EB852, 0x3F6147AE, 0x3F63D70A,
+0x3F66, 0x3F68F5C3, 0x3F6B851F, 0x3F6E147B, 0x3F70A3D7, 0x3F73,
+0x3F75C28F, 0x3F7851EC, 0x3F7AE148, 0x3F7D70A4, 0x3F80
+};
+
+static void podhd_set_monitor_level(struct usb_line6_podhd *podhd, int value)
+{
+ unsigned int fl;
+ static const unsigned char msg[16] = {
+ /* Chunk is 0xc bytes (without first word) */
+ 0x0c, 0x00,
+ /* First chunk in the message */
+ 0x01, 0x00,
+ /* Message size is 2 4-byte words */
+ 0x02, 0x00,
+ /* Unknown */
+ 0x04, 0x41,
+ /* Unknown */
+ 0x04, 0x00, 0x13, 0x00,
+ /* Volume, LE float32, 0.0 - 1.0 */
+ 0x00, 0x00, 0x00, 0x00
+ };
+ unsigned char *buf;
+
+ buf = kmalloc(sizeof(msg), GFP_ATOMIC);
+ memcpy(buf, msg, sizeof(msg));
+
+ if (value < 0)
+ value = 0;
+
+ if (value >= A
Re: [PATCH] ALSA: line6: add hw monitor volume control for POD HD500
On Sat, May 23, 2020 at 10:39 AM Vasily Khoruzhick wrote:
>
> Add hw monitor volume control for POD HD500. The same change may
> work for HD500X but I don't have it to test.
Ugh, found a bug in it right after sending (value is clamped to
ARRAY_SIZE() while should be to ARRAY_SIZE()-1)
Please discard this patch, I'll send v2 shortly.
> Signed-off-by: Vasily Khoruzhick
> ---
> sound/usb/line6/driver.c | 3 +-
> sound/usb/line6/driver.h | 4 ++
> sound/usb/line6/podhd.c | 124 ++-
> 3 files changed, 129 insertions(+), 2 deletions(-)
>
> diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
> index 7629116f570e..597a36c0a51d 100644
> --- a/sound/usb/line6/driver.c
> +++ b/sound/usb/line6/driver.c
> @@ -97,7 +97,7 @@ static void line6_stop_listen(struct usb_line6 *line6)
> /*
> Send raw message in pieces of wMaxPacketSize bytes.
> */
> -static int line6_send_raw_message(struct usb_line6 *line6, const char
> *buffer,
> +int line6_send_raw_message(struct usb_line6 *line6, const char *buffer,
> int size)
> {
> int i, done = 0;
> @@ -132,6 +132,7 @@ static int line6_send_raw_message(struct usb_line6
> *line6, const char *buffer,
>
> return done;
> }
> +EXPORT_SYMBOL(line6_send_raw_message);
>
> /*
> Notification of completion of asynchronous request transmission.
> diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
> index 1a4e3700c80c..62c686bed0ca 100644
> --- a/sound/usb/line6/driver.h
> +++ b/sound/usb/line6/driver.h
> @@ -108,6 +108,8 @@ enum {
> LINE6_CAP_CONTROL_MIDI = 1 << 4,
> /* device provides low-level information */
> LINE6_CAP_CONTROL_INFO = 1 << 5,
> + /* device provides hardware monitoring volume control */
> + LINE6_CAP_HWMON_CTL = 1 << 6,
> };
>
> /*
> @@ -185,6 +187,8 @@ extern int line6_read_data(struct usb_line6 *line6,
> unsigned address,
>void *data, unsigned datalen);
> extern int line6_read_serial_number(struct usb_line6 *line6,
> u32 *serial_number);
> +extern int line6_send_raw_message(struct usb_line6 *line6,
> + const char *buffer, int size);
> extern int line6_send_raw_message_async(struct usb_line6 *line6,
> const char *buffer, int size);
> extern int line6_send_sysex_message(struct usb_line6 *line6,
> diff --git a/sound/usb/line6/podhd.c b/sound/usb/line6/podhd.c
> index e39dc85c355a..a40115625c01 100644
> --- a/sound/usb/line6/podhd.c
> +++ b/sound/usb/line6/podhd.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "driver.h"
> @@ -37,6 +38,9 @@ struct usb_line6_podhd {
>
> /* Firmware version */
> int firmware_version;
> +
> + /* Monitor level */
> + int monitor_level;
> };
>
> #define line6_to_podhd(x) container_of(x, struct usb_line6_podhd, line6)
> @@ -250,6 +254,115 @@ static void podhd_disconnect(struct usb_line6 *line6)
> }
> }
>
> +static const unsigned int float_zero_to_one_lookup[] = {
> +0x, 0x3C23D70A, 0x3CA3D70A, 0x3CF5C28F, 0x3D23D70A, 0x3D4D,
> +0x3D75C28F, 0x3D8F5C29, 0x3DA3D70A, 0x3DB851EC, 0x3DCD, 0x3DE147AE,
> +0x3DF5C28F, 0x3E051EB8, 0x3E0F5C29, 0x3E1A, 0x3E23D70A, 0x3E2E147B,
> +0x3E3851EC, 0x3E428F5C, 0x3E4D, 0x3E570A3D, 0x3E6147AE, 0x3E6B851F,
> +0x3E75C28F, 0x3E80, 0x3E851EB8, 0x3E8A3D71, 0x3E8F5C29, 0x3E947AE1,
> +0x3E9A, 0x3E9EB852, 0x3EA3D70A, 0x3EA8F5C3, 0x3EAE147B, 0x3EB3,
> +0x3EB851EC, 0x3EBD70A4, 0x3EC28F5C, 0x3EC7AE14, 0x3ECD, 0x3ED1EB85,
> +0x3ED70A3D, 0x3EDC28F6, 0x3EE147AE, 0x3EE6, 0x3EEB851F, 0x3EF0A3D7,
> +0x3EF5C28F, 0x3EFAE148, 0x3F00, 0x3F028F5C, 0x3F051EB8, 0x3F07AE14,
> +0x3F0A3D71, 0x3F0D, 0x3F0F5C29, 0x3F11EB85, 0x3F147AE1, 0x3F170A3D,
> +0x3F1A, 0x3F1C28F6, 0x3F1EB852, 0x3F2147AE, 0x3F23D70A, 0x3F26,
> +0x3F28F5C3, 0x3F2B851F, 0x3F2E147B, 0x3F30A3D7, 0x3F33, 0x3F35C28F,
> +0x3F3851EC, 0x3F3AE148, 0x3F3D70A4, 0x3F40, 0x3F428F5C, 0x3F451EB8,
> +0x3F47AE14, 0x3F4A3D71, 0x3F4D, 0x3F4F5C29, 0x3F51EB85, 0x3F547AE1,
> +0x3F570A3D, 0x3F5A, 0x3F5C28F6, 0x3F5EB852, 0x3F6147AE, 0x3F63D70A,
> +0x3F66, 0x3F68F5C3, 0x3F6B851F, 0x3F6E147B, 0x3F70A3D7, 0x3F73,
> +0x3F75C28F, 0x3F7851EC, 0x3F7AE148, 0x3F7D70A4, 0x3F80
> +};
> +
> +static void podhd_set_monitor_level(struct usb_line6_podhd *podhd, int value)
> +{
> + unsigned int fl;
> + static const unsigned char msg[16] = {
>
[PATCH] ALSA: line6: add hw monitor volume control for POD HD500
Add hw monitor volume control for POD HD500. The same change may
work for HD500X but I don't have it to test.
Signed-off-by: Vasily Khoruzhick
---
sound/usb/line6/driver.c | 3 +-
sound/usb/line6/driver.h | 4 ++
sound/usb/line6/podhd.c | 124 ++-
3 files changed, 129 insertions(+), 2 deletions(-)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 7629116f570e..597a36c0a51d 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -97,7 +97,7 @@ static void line6_stop_listen(struct usb_line6 *line6)
/*
Send raw message in pieces of wMaxPacketSize bytes.
*/
-static int line6_send_raw_message(struct usb_line6 *line6, const char *buffer,
+int line6_send_raw_message(struct usb_line6 *line6, const char *buffer,
int size)
{
int i, done = 0;
@@ -132,6 +132,7 @@ static int line6_send_raw_message(struct usb_line6 *line6,
const char *buffer,
return done;
}
+EXPORT_SYMBOL(line6_send_raw_message);
/*
Notification of completion of asynchronous request transmission.
diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
index 1a4e3700c80c..62c686bed0ca 100644
--- a/sound/usb/line6/driver.h
+++ b/sound/usb/line6/driver.h
@@ -108,6 +108,8 @@ enum {
LINE6_CAP_CONTROL_MIDI = 1 << 4,
/* device provides low-level information */
LINE6_CAP_CONTROL_INFO = 1 << 5,
+ /* device provides hardware monitoring volume control */
+ LINE6_CAP_HWMON_CTL = 1 << 6,
};
/*
@@ -185,6 +187,8 @@ extern int line6_read_data(struct usb_line6 *line6,
unsigned address,
void *data, unsigned datalen);
extern int line6_read_serial_number(struct usb_line6 *line6,
u32 *serial_number);
+extern int line6_send_raw_message(struct usb_line6 *line6,
+ const char *buffer, int size);
extern int line6_send_raw_message_async(struct usb_line6 *line6,
const char *buffer, int size);
extern int line6_send_sysex_message(struct usb_line6 *line6,
diff --git a/sound/usb/line6/podhd.c b/sound/usb/line6/podhd.c
index e39dc85c355a..a40115625c01 100644
--- a/sound/usb/line6/podhd.c
+++ b/sound/usb/line6/podhd.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include "driver.h"
@@ -37,6 +38,9 @@ struct usb_line6_podhd {
/* Firmware version */
int firmware_version;
+
+ /* Monitor level */
+ int monitor_level;
};
#define line6_to_podhd(x) container_of(x, struct usb_line6_podhd, line6)
@@ -250,6 +254,115 @@ static void podhd_disconnect(struct usb_line6 *line6)
}
}
+static const unsigned int float_zero_to_one_lookup[] = {
+0x, 0x3C23D70A, 0x3CA3D70A, 0x3CF5C28F, 0x3D23D70A, 0x3D4D,
+0x3D75C28F, 0x3D8F5C29, 0x3DA3D70A, 0x3DB851EC, 0x3DCD, 0x3DE147AE,
+0x3DF5C28F, 0x3E051EB8, 0x3E0F5C29, 0x3E1A, 0x3E23D70A, 0x3E2E147B,
+0x3E3851EC, 0x3E428F5C, 0x3E4D, 0x3E570A3D, 0x3E6147AE, 0x3E6B851F,
+0x3E75C28F, 0x3E80, 0x3E851EB8, 0x3E8A3D71, 0x3E8F5C29, 0x3E947AE1,
+0x3E9A, 0x3E9EB852, 0x3EA3D70A, 0x3EA8F5C3, 0x3EAE147B, 0x3EB3,
+0x3EB851EC, 0x3EBD70A4, 0x3EC28F5C, 0x3EC7AE14, 0x3ECD, 0x3ED1EB85,
+0x3ED70A3D, 0x3EDC28F6, 0x3EE147AE, 0x3EE6, 0x3EEB851F, 0x3EF0A3D7,
+0x3EF5C28F, 0x3EFAE148, 0x3F00, 0x3F028F5C, 0x3F051EB8, 0x3F07AE14,
+0x3F0A3D71, 0x3F0D, 0x3F0F5C29, 0x3F11EB85, 0x3F147AE1, 0x3F170A3D,
+0x3F1A, 0x3F1C28F6, 0x3F1EB852, 0x3F2147AE, 0x3F23D70A, 0x3F26,
+0x3F28F5C3, 0x3F2B851F, 0x3F2E147B, 0x3F30A3D7, 0x3F33, 0x3F35C28F,
+0x3F3851EC, 0x3F3AE148, 0x3F3D70A4, 0x3F40, 0x3F428F5C, 0x3F451EB8,
+0x3F47AE14, 0x3F4A3D71, 0x3F4D, 0x3F4F5C29, 0x3F51EB85, 0x3F547AE1,
+0x3F570A3D, 0x3F5A, 0x3F5C28F6, 0x3F5EB852, 0x3F6147AE, 0x3F63D70A,
+0x3F66, 0x3F68F5C3, 0x3F6B851F, 0x3F6E147B, 0x3F70A3D7, 0x3F73,
+0x3F75C28F, 0x3F7851EC, 0x3F7AE148, 0x3F7D70A4, 0x3F80
+};
+
+static void podhd_set_monitor_level(struct usb_line6_podhd *podhd, int value)
+{
+ unsigned int fl;
+ static const unsigned char msg[16] = {
+ /* Chunk is 0xc bytes (without first word) */
+ 0x0c, 0x00,
+ /* First chunk in the message */
+ 0x01, 0x00,
+ /* Message size is 2 4-byte words */
+ 0x02, 0x00,
+ /* Unknown */
+ 0x04, 0x41,
+ /* Unknown */
+ 0x04, 0x00, 0x13, 0x00,
+ /* Volume, LE float32, 0.0 - 1.0 */
+ 0x00, 0x00, 0x00, 0x00
+ };
+ unsigned char *buf;
+
+ buf = kmalloc(sizeof(msg), GFP_ATOMIC);
+ memcpy(buf, msg, sizeof(msg));
+
+ if (value < 0)
+ value = 0;
+
+ if (value > ARRAY_SIZE(float_zero_to_one_lookup))
+ value = ARRAY_SIZE(float
Re: [PATCH 0/2] ALSA: line6: hwdep: add support for poll and non-blocking read
On Sat, May 2, 2020 at 1:32 PM Takashi Iwai wrote: > > On Sat, 02 May 2020 21:31:18 +0200, > Vasily Khoruzhick wrote: > > > > This series adds support for polling and non-blocking read for hwdep > > interface. This allows apps to listen to HW events without using busy > > loop. > > > > Example of app that uses hwdep interface for POD HD500 can be found > > here: https://github.com/anarsoul/line6_hwdep_test > > > > Vasily Khoruzhick (2): > > ALSA: line6: hwdep: add support for O_NONBLOCK opening mode > > ALSA: line6: Add poll callback for hwdep > > Looks like a nice extension. Applied both patches now to for-next > branch. Thanks for such a prompt response! > > thanks, > > Takashi
[PATCH 0/2] ALSA: line6: hwdep: add support for poll and non-blocking read
This series adds support for polling and non-blocking read for hwdep interface. This allows apps to listen to HW events without using busy loop. Example of app that uses hwdep interface for POD HD500 can be found here: https://github.com/anarsoul/line6_hwdep_test Vasily Khoruzhick (2): ALSA: line6: hwdep: add support for O_NONBLOCK opening mode ALSA: line6: Add poll callback for hwdep sound/usb/line6/driver.c | 20 sound/usb/line6/driver.h | 1 + 2 files changed, 21 insertions(+) -- 2.26.2
[PATCH 2/2] ALSA: line6: Add poll callback for hwdep
At least POD HD500 uses message-based communication, both sides can
send messages. Add poll callback so application can wait for device
messages without using busy loop.
Signed-off-by: Vasily Khoruzhick
---
sound/usb/line6/driver.c | 16
1 file changed, 16 insertions(+)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 86adf87d57f0..7629116f570e 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -630,11 +630,27 @@ line6_hwdep_write(struct snd_hwdep *hwdep, const char
__user *data, long count,
return rv;
}
+static __poll_t
+line6_hwdep_poll(struct snd_hwdep *hwdep, struct file *file, poll_table *wait)
+{
+ __poll_t rv;
+ struct usb_line6 *line6 = hwdep->private_data;
+
+ poll_wait(file, >messages.wait_queue, wait);
+
+ mutex_lock(>messages.read_lock);
+ rv = kfifo_len(>messages.fifo) == 0 ? 0 : EPOLLIN | EPOLLRDNORM;
+ mutex_unlock(>messages.read_lock);
+
+ return rv;
+}
+
static const struct snd_hwdep_ops hwdep_ops = {
.open= line6_hwdep_open,
.release = line6_hwdep_release,
.read= line6_hwdep_read,
.write = line6_hwdep_write,
+ .poll= line6_hwdep_poll,
};
/* Insert into circular buffer */
--
2.26.2
[PATCH 1/2] ALSA: line6: hwdep: add support for O_NONBLOCK opening mode
Currently line6 hwdep interface ignores O_NONBLOCK flag when
opening device and it renders it somewhat useless when using poll.
Check for O_NONBLOCK flag when opening device and don't block read()
if it is set.
Signed-off-by: Vasily Khoruzhick
---
sound/usb/line6/driver.c | 4
sound/usb/line6/driver.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 4f096685ed65..86adf87d57f0 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -550,6 +550,7 @@ static int line6_hwdep_open(struct snd_hwdep *hw, struct
file *file)
/* NOTE: hwdep layer provides atomicity here */
line6->messages.active = 1;
+ line6->messages.nonblock = file->f_flags & O_NONBLOCK ? 1 : 0;
return 0;
}
@@ -579,6 +580,9 @@ line6_hwdep_read(struct snd_hwdep *hwdep, char __user *buf,
long count,
while (kfifo_len(>messages.fifo) == 0) {
mutex_unlock(>messages.read_lock);
+ if (line6->messages.nonblock)
+ return -EAGAIN;
+
rv = wait_event_interruptible(
line6->messages.wait_queue,
kfifo_len(>messages.fifo) != 0);
diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
index e5e572ed5f30..1a4e3700c80c 100644
--- a/sound/usb/line6/driver.h
+++ b/sound/usb/line6/driver.h
@@ -163,6 +163,7 @@ struct usb_line6 {
struct mutex read_lock;
wait_queue_head_t wait_queue;
unsigned int active:1;
+ unsigned int nonblock:1;
STRUCT_KFIFO_REC_2(LINE6_BUFSIZE_LISTEN *
LINE6_RAW_MESSAGES_MAXCOUNT)
fifo;
} messages;
--
2.26.2
Re: [PATCH v5 08/18] thermal: sun8i: support mod clocks
On Sun, Aug 25, 2019 at 9:14 AM Frank Lee wrote:
>
> HI Vasily,
Hi Yangtao,
Sorry for the late reply,
> On Wed, Aug 14, 2019 at 11:01 AM Vasily Khoruzhick wrote:
> >
> > On Tue, Aug 13, 2019 at 1:06 PM Ondřej Jirman wrote:
> > >
> > > On Mon, Aug 12, 2019 at 04:54:15PM -0700, Vasily Khoruzhick wrote:
> > > > On Mon, Aug 12, 2019 at 4:46 PM Frank Lee wrote:
> > > > >
> > > > > HI Vasily,
> > > > >
> > > > > On Sat, Aug 10, 2019 at 2:17 PM Vasily Khoruzhick
> > > > > wrote:
> > > > > >
> > > > > > On Fri, Aug 9, 2019 at 10:31 PM Yangtao Li
> > > > > > wrote:
> > > > > > >
> > > > > > > H3 has extra clock, so introduce something in
> > > > > > > ths_thermal_chip/ths_device
> > > > > > > and adds the process of the clock.
> > > > > > >
> > > > > > > This is pre-work for supprt it.
> > > > > > >
> > > > > > > Signed-off-by: Yangtao Li
> > > > > > > ---
> > > > > > > drivers/thermal/sun8i_thermal.c | 17 -
> > > > > > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/drivers/thermal/sun8i_thermal.c
> > > > > > > b/drivers/thermal/sun8i_thermal.c
> > > > > > > index b934bc81eba7..6f4294c2aba7 100644
> > > > > > > --- a/drivers/thermal/sun8i_thermal.c
> > > > > > > +++ b/drivers/thermal/sun8i_thermal.c
> > > > > > > @@ -54,6 +54,7 @@ struct tsensor {
> > > > > > > };
> > > > > > >
> > > > > > > struct ths_thermal_chip {
> > > > > > > + boolhas_mod_clk;
> > > > > > > int sensor_num;
> > > > > > > int offset;
> > > > > > > int scale;
> > > > > > > @@ -69,6 +70,7 @@ struct ths_device {
> > > > > > > struct regmap *regmap;
> > > > > > > struct reset_control*reset;
> > > > > > > struct clk *bus_clk;
> > > > > > > + struct clk *mod_clk;
> > > > > > > struct tsensor
> > > > > > > sensor[MAX_SENSOR_NUM];
> > > > > > > };
> > > > > > >
> > > > > > > @@ -274,6 +276,12 @@ static int sun8i_ths_resource_init(struct
> > > > > > > ths_device *tmdev)
> > > > > > > if (IS_ERR(tmdev->bus_clk))
> > > > > > > return PTR_ERR(tmdev->bus_clk);
> > > > > > >
> > > > > > > + if (tmdev->chip->has_mod_clk) {
> > > > > > > + tmdev->mod_clk = devm_clk_get(>dev, "mod");
> > > > > > > + if (IS_ERR(tmdev->mod_clk))
> > > > > > > + return PTR_ERR(tmdev->mod_clk);
> > > > > > > + }
> > > > > > > +
> > > > > > > ret = reset_control_deassert(tmdev->reset);
> > > > > > > if (ret)
> > > > > > > return ret;
> > > > > > > @@ -282,12 +290,18 @@ static int sun8i_ths_resource_init(struct
> > > > > > > ths_device *tmdev)
> > > > > > > if (ret)
> > > > > > > goto assert_reset;
> > > > > > >
> > > > > > > - ret = sun50i_ths_calibrate(tmdev);
> > > > > > > + ret = clk_prepare_enable(tmdev->mod_clk);
> > > > > >
> > > > > > You have to set rate of modclk before enabling it since you can't
> > > > > > rely
> > > > > > on whatever bootloader left for you.
> > > > > >
> > > > > > Also I found that parameters you're using for PC_TEMP_PERIOD, ACQ0
> > > > > > and
> > > > > > ACQ1 are too aggressive and may result in high interrupt rate to the
> > > > > > point when it may stall RCU.
Re: [PATCH v5 08/18] thermal: sun8i: support mod clocks
On Tue, Aug 13, 2019 at 1:06 PM Ondřej Jirman wrote:
>
> On Mon, Aug 12, 2019 at 04:54:15PM -0700, Vasily Khoruzhick wrote:
> > On Mon, Aug 12, 2019 at 4:46 PM Frank Lee wrote:
> > >
> > > HI Vasily,
> > >
> > > On Sat, Aug 10, 2019 at 2:17 PM Vasily Khoruzhick
> > > wrote:
> > > >
> > > > On Fri, Aug 9, 2019 at 10:31 PM Yangtao Li
> > > > wrote:
> > > > >
> > > > > H3 has extra clock, so introduce something in
> > > > > ths_thermal_chip/ths_device
> > > > > and adds the process of the clock.
> > > > >
> > > > > This is pre-work for supprt it.
> > > > >
> > > > > Signed-off-by: Yangtao Li
> > > > > ---
> > > > > drivers/thermal/sun8i_thermal.c | 17 -
> > > > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/thermal/sun8i_thermal.c
> > > > > b/drivers/thermal/sun8i_thermal.c
> > > > > index b934bc81eba7..6f4294c2aba7 100644
> > > > > --- a/drivers/thermal/sun8i_thermal.c
> > > > > +++ b/drivers/thermal/sun8i_thermal.c
> > > > > @@ -54,6 +54,7 @@ struct tsensor {
> > > > > };
> > > > >
> > > > > struct ths_thermal_chip {
> > > > > + boolhas_mod_clk;
> > > > > int sensor_num;
> > > > > int offset;
> > > > > int scale;
> > > > > @@ -69,6 +70,7 @@ struct ths_device {
> > > > > struct regmap *regmap;
> > > > > struct reset_control*reset;
> > > > > struct clk *bus_clk;
> > > > > + struct clk *mod_clk;
> > > > > struct tsensor
> > > > > sensor[MAX_SENSOR_NUM];
> > > > > };
> > > > >
> > > > > @@ -274,6 +276,12 @@ static int sun8i_ths_resource_init(struct
> > > > > ths_device *tmdev)
> > > > > if (IS_ERR(tmdev->bus_clk))
> > > > > return PTR_ERR(tmdev->bus_clk);
> > > > >
> > > > > + if (tmdev->chip->has_mod_clk) {
> > > > > + tmdev->mod_clk = devm_clk_get(>dev, "mod");
> > > > > + if (IS_ERR(tmdev->mod_clk))
> > > > > + return PTR_ERR(tmdev->mod_clk);
> > > > > + }
> > > > > +
> > > > > ret = reset_control_deassert(tmdev->reset);
> > > > > if (ret)
> > > > > return ret;
> > > > > @@ -282,12 +290,18 @@ static int sun8i_ths_resource_init(struct
> > > > > ths_device *tmdev)
> > > > > if (ret)
> > > > > goto assert_reset;
> > > > >
> > > > > - ret = sun50i_ths_calibrate(tmdev);
> > > > > + ret = clk_prepare_enable(tmdev->mod_clk);
> > > >
> > > > You have to set rate of modclk before enabling it since you can't rely
> > > > on whatever bootloader left for you.
> > > >
> > > > Also I found that parameters you're using for PC_TEMP_PERIOD, ACQ0 and
> > > > ACQ1 are too aggressive and may result in high interrupt rate to the
> > > > point when it may stall RCU. I changed driver a bit to use params from
> > > > Philipp Rossak's work (modclk set to 4MHz, PC_TEMP_PERIOD is 7, ACQ0
> > > > is 255, ACQ1 is 63) and it fixed RCU stalls for me, see [1] for
> > > > details.
> > >
> > > Why is the RCU stall happening, is it caused by a deadlock?
> > > Can you provide log information and your configuration?
> > > I am a bit curious.
> >
> > It's not deadlock, I believe it just can't handle that many interrupts
> > when running at lowest CPU frequency. Even with Philipp's settings
> > there's ~20 interrupts a second from ths. I don't remember how many
> > interrupts were there with your settings.
> >
> > Unfortunately there's nothing interesting in backtraces, I'm using
> > Pine64-LTS board.
>
> Recently there was a similar issue, with buggy CCU driver that caused
> CIR interrupts being fired const
Re: [PATCH v5 08/18] thermal: sun8i: support mod clocks
On Mon, Aug 12, 2019 at 4:46 PM Frank Lee wrote:
>
> HI Vasily,
>
> On Sat, Aug 10, 2019 at 2:17 PM Vasily Khoruzhick wrote:
> >
> > On Fri, Aug 9, 2019 at 10:31 PM Yangtao Li wrote:
> > >
> > > H3 has extra clock, so introduce something in ths_thermal_chip/ths_device
> > > and adds the process of the clock.
> > >
> > > This is pre-work for supprt it.
> > >
> > > Signed-off-by: Yangtao Li
> > > ---
> > > drivers/thermal/sun8i_thermal.c | 17 -
> > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/thermal/sun8i_thermal.c
> > > b/drivers/thermal/sun8i_thermal.c
> > > index b934bc81eba7..6f4294c2aba7 100644
> > > --- a/drivers/thermal/sun8i_thermal.c
> > > +++ b/drivers/thermal/sun8i_thermal.c
> > > @@ -54,6 +54,7 @@ struct tsensor {
> > > };
> > >
> > > struct ths_thermal_chip {
> > > + boolhas_mod_clk;
> > > int sensor_num;
> > > int offset;
> > > int scale;
> > > @@ -69,6 +70,7 @@ struct ths_device {
> > > struct regmap *regmap;
> > > struct reset_control*reset;
> > > struct clk *bus_clk;
> > > + struct clk *mod_clk;
> > > struct tsensor sensor[MAX_SENSOR_NUM];
> > > };
> > >
> > > @@ -274,6 +276,12 @@ static int sun8i_ths_resource_init(struct ths_device
> > > *tmdev)
> > > if (IS_ERR(tmdev->bus_clk))
> > > return PTR_ERR(tmdev->bus_clk);
> > >
> > > + if (tmdev->chip->has_mod_clk) {
> > > + tmdev->mod_clk = devm_clk_get(>dev, "mod");
> > > + if (IS_ERR(tmdev->mod_clk))
> > > + return PTR_ERR(tmdev->mod_clk);
> > > + }
> > > +
> > > ret = reset_control_deassert(tmdev->reset);
> > > if (ret)
> > > return ret;
> > > @@ -282,12 +290,18 @@ static int sun8i_ths_resource_init(struct
> > > ths_device *tmdev)
> > > if (ret)
> > > goto assert_reset;
> > >
> > > - ret = sun50i_ths_calibrate(tmdev);
> > > + ret = clk_prepare_enable(tmdev->mod_clk);
> >
> > You have to set rate of modclk before enabling it since you can't rely
> > on whatever bootloader left for you.
> >
> > Also I found that parameters you're using for PC_TEMP_PERIOD, ACQ0 and
> > ACQ1 are too aggressive and may result in high interrupt rate to the
> > point when it may stall RCU. I changed driver a bit to use params from
> > Philipp Rossak's work (modclk set to 4MHz, PC_TEMP_PERIOD is 7, ACQ0
> > is 255, ACQ1 is 63) and it fixed RCU stalls for me, see [1] for
> > details.
>
> Why is the RCU stall happening, is it caused by a deadlock?
> Can you provide log information and your configuration?
> I am a bit curious.
It's not deadlock, I believe it just can't handle that many interrupts
when running at lowest CPU frequency. Even with Philipp's settings
there's ~20 interrupts a second from ths. I don't remember how many
interrupts were there with your settings.
Unfortunately there's nothing interesting in backtraces, I'm using
Pine64-LTS board.
> Thx,
> Yangtao
>
> >
> > [1]
> > https://github.com/anarsoul/linux-2.6/commit/46b8bb0fe2ccd1cd88fa9181a2ecbf79e8d513b2
> >
> >
> > > if (ret)
> > > goto bus_disable;
> > >
> > > + ret = sun50i_ths_calibrate(tmdev);
> > > + if (ret)
> > > + goto mod_disable;
> > > +
> > > return 0;
> > >
> > > +mod_disable:
> > > + clk_disable_unprepare(tmdev->mod_clk);
> > > bus_disable:
> > > clk_disable_unprepare(tmdev->bus_clk);
> > > assert_reset:
> > > @@ -395,6 +409,7 @@ static int sun8i_ths_remove(struct platform_device
> > > *pdev)
> > > {
> > > struct ths_device *tmdev = platform_get_drvdata(pdev);
> > >
> > > + clk_disable_unprepare(tmdev->mod_clk);
> > > clk_disable_unprepare(tmdev->bus_clk);
> > > reset_control_assert(tmdev->reset);
> > >
> > > --
> > > 2.17.1
> > >
> > >
> > > ___
> > > linux-arm-kernel mailing list
> > > linux-arm-ker...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v5 08/18] thermal: sun8i: support mod clocks
On Fri, Aug 9, 2019 at 10:31 PM Yangtao Li wrote:
>
> H3 has extra clock, so introduce something in ths_thermal_chip/ths_device
> and adds the process of the clock.
>
> This is pre-work for supprt it.
>
> Signed-off-by: Yangtao Li
> ---
> drivers/thermal/sun8i_thermal.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> index b934bc81eba7..6f4294c2aba7 100644
> --- a/drivers/thermal/sun8i_thermal.c
> +++ b/drivers/thermal/sun8i_thermal.c
> @@ -54,6 +54,7 @@ struct tsensor {
> };
>
> struct ths_thermal_chip {
> + boolhas_mod_clk;
> int sensor_num;
> int offset;
> int scale;
> @@ -69,6 +70,7 @@ struct ths_device {
> struct regmap *regmap;
> struct reset_control*reset;
> struct clk *bus_clk;
> + struct clk *mod_clk;
> struct tsensor sensor[MAX_SENSOR_NUM];
> };
>
> @@ -274,6 +276,12 @@ static int sun8i_ths_resource_init(struct ths_device
> *tmdev)
> if (IS_ERR(tmdev->bus_clk))
> return PTR_ERR(tmdev->bus_clk);
>
> + if (tmdev->chip->has_mod_clk) {
> + tmdev->mod_clk = devm_clk_get(>dev, "mod");
> + if (IS_ERR(tmdev->mod_clk))
> + return PTR_ERR(tmdev->mod_clk);
> + }
> +
> ret = reset_control_deassert(tmdev->reset);
> if (ret)
> return ret;
> @@ -282,12 +290,18 @@ static int sun8i_ths_resource_init(struct ths_device
> *tmdev)
> if (ret)
> goto assert_reset;
>
> - ret = sun50i_ths_calibrate(tmdev);
> + ret = clk_prepare_enable(tmdev->mod_clk);
You have to set rate of modclk before enabling it since you can't rely
on whatever bootloader left for you.
Also I found that parameters you're using for PC_TEMP_PERIOD, ACQ0 and
ACQ1 are too aggressive and may result in high interrupt rate to the
point when it may stall RCU. I changed driver a bit to use params from
Philipp Rossak's work (modclk set to 4MHz, PC_TEMP_PERIOD is 7, ACQ0
is 255, ACQ1 is 63) and it fixed RCU stalls for me, see [1] for
details.
[1]
https://github.com/anarsoul/linux-2.6/commit/46b8bb0fe2ccd1cd88fa9181a2ecbf79e8d513b2
> if (ret)
> goto bus_disable;
>
> + ret = sun50i_ths_calibrate(tmdev);
> + if (ret)
> + goto mod_disable;
> +
> return 0;
>
> +mod_disable:
> + clk_disable_unprepare(tmdev->mod_clk);
> bus_disable:
> clk_disable_unprepare(tmdev->bus_clk);
> assert_reset:
> @@ -395,6 +409,7 @@ static int sun8i_ths_remove(struct platform_device *pdev)
> {
> struct ths_device *tmdev = platform_get_drvdata(pdev);
>
> + clk_disable_unprepare(tmdev->mod_clk);
> clk_disable_unprepare(tmdev->bus_clk);
> reset_control_assert(tmdev->reset);
>
> --
> 2.17.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [linux-sunxi] Re: [PATCH 1/1] nvmem: sunxi_sid: fix A64 SID controller support
On Wed, Jul 31, 2019 at 1:43 AM Chen-Yu Tsai wrote:
>
> On Wed, Jul 31, 2019 at 3:15 PM Stefan Mavrodiev wrote:
> >
> > Like in H3, A64 SID controller doesn't return correct data
> > when using direct access. It appears that on A64, SID needs
> > 8 bytes of word_size.
> >
> > Workaround is to enable read by registers.
I came up with identical patch while adding A64 support into
sun8i-thermal driver, so:
> >
> > Signed-off-by: Stefan Mavrodiev
>
> Acked-by: Chen-Yu Tsai
Tested-by: Vasily Khoruzhick
>
> And for single patches, you don't need to write a separate cover letter.
> Just put whatever you need to add after the "---" separator.
>
> > ---
> > drivers/nvmem/sunxi_sid.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
> > index a079a80ddf2c..e26ef1bbf198 100644
> > --- a/drivers/nvmem/sunxi_sid.c
> > +++ b/drivers/nvmem/sunxi_sid.c
> > @@ -186,6 +186,7 @@ static const struct sunxi_sid_cfg sun8i_h3_cfg = {
> > static const struct sunxi_sid_cfg sun50i_a64_cfg = {
> > .value_offset = 0x200,
> > .size = 0x100,
> > + .need_register_readout = true,
> > };
> >
> > static const struct sunxi_sid_cfg sun50i_h6_cfg = {
> > --
> > 2.17.1
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/linux-sunxi/CAGb2v64tzMypnB5Ho2A-gWPk2yYsmH9tNn%2BOKfb51c%2Bd6pK%3Dkw%40mail.gmail.com.
Re: [PATCH v4 00/11] add thermal driver for h6
Hey Yangtao, Are you planning to send v5 anytime soon? On Sat, Jul 13, 2019 at 11:01 AM Vasily Khoruzhick wrote: > > On Wed, Jul 10, 2019 at 4:09 PM Vasily Khoruzhick wrote: > > > > On Sun, Jun 23, 2019 at 9:42 AM Yangtao Li wrote: > > > > > > This patchset add support for H3 and H6 thermal sensor. > > > > > > BTY, do a cleanup in thermal makfile. > > > > > > Yangtao Li (11): > > > thermal: sun8i: add thermal driver for h6 > > > dt-bindings: thermal: add binding document for h6 thermal controller > > > thermal: fix indentation in makefile > > > thermal: sun8i: get ths sensor number from device compatible > > > thermal: sun8i: rework for sun8i_ths_get_temp() > > > thermal: sun8i: get ths init func from device compatible > > > thermal: sun8i: rework for ths irq handler func > > > thermal: sun8i: support ahb clocks > > > thermal: sun8i: rework for ths calibrate func > > > dt-bindings: thermal: add binding document for h3 thermal controller > > > thermal: sun8i: add thermal driver for h3 > > > > It would be nice to add dts changes to this series. It's unlikely that > > you'll get any "Tested-by" otherwise. > > I added A64 support on top of this series, see > https://github.com/anarsoul/linux-2.6/tree/v5.2-thermal > > Branch also contains patches to enable DVFS on A64, feel free to > cherry pick only those related to thermal driver if you want to > include A64 support into v5 series. > > > > > > .../bindings/thermal/sun8i-thermal.yaml | 94 +++ > > > MAINTAINERS | 7 + > > > drivers/thermal/Kconfig | 14 + > > > drivers/thermal/Makefile | 9 +- > > > drivers/thermal/sun8i_thermal.c | 534 ++ > > > 5 files changed, 654 insertions(+), 4 deletions(-) > > > create mode 100644 > > > Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml > > > create mode 100644 drivers/thermal/sun8i_thermal.c > > > > > > --- > > > v4: > > > -add h3 support > > > -fix yaml file > > > --- > > > 2.17.1 > > > > > > > > > ___ > > > linux-arm-kernel mailing list > > > linux-arm-ker...@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v4 00/11] add thermal driver for h6
On Wed, Jul 10, 2019 at 4:09 PM Vasily Khoruzhick wrote: > > On Sun, Jun 23, 2019 at 9:42 AM Yangtao Li wrote: > > > > This patchset add support for H3 and H6 thermal sensor. > > > > BTY, do a cleanup in thermal makfile. > > > > Yangtao Li (11): > > thermal: sun8i: add thermal driver for h6 > > dt-bindings: thermal: add binding document for h6 thermal controller > > thermal: fix indentation in makefile > > thermal: sun8i: get ths sensor number from device compatible > > thermal: sun8i: rework for sun8i_ths_get_temp() > > thermal: sun8i: get ths init func from device compatible > > thermal: sun8i: rework for ths irq handler func > > thermal: sun8i: support ahb clocks > > thermal: sun8i: rework for ths calibrate func > > dt-bindings: thermal: add binding document for h3 thermal controller > > thermal: sun8i: add thermal driver for h3 > > It would be nice to add dts changes to this series. It's unlikely that > you'll get any "Tested-by" otherwise. I added A64 support on top of this series, see https://github.com/anarsoul/linux-2.6/tree/v5.2-thermal Branch also contains patches to enable DVFS on A64, feel free to cherry pick only those related to thermal driver if you want to include A64 support into v5 series. > > > .../bindings/thermal/sun8i-thermal.yaml | 94 +++ > > MAINTAINERS | 7 + > > drivers/thermal/Kconfig | 14 + > > drivers/thermal/Makefile | 9 +- > > drivers/thermal/sun8i_thermal.c | 534 ++ > > 5 files changed, 654 insertions(+), 4 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml > > create mode 100644 drivers/thermal/sun8i_thermal.c > > > > --- > > v4: > > -add h3 support > > -fix yaml file > > --- > > 2.17.1 > > > > > > ___ > > linux-arm-kernel mailing list > > linux-arm-ker...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v4 00/11] add thermal driver for h6
On Sun, Jun 23, 2019 at 9:42 AM Yangtao Li wrote: > > This patchset add support for H3 and H6 thermal sensor. > > BTY, do a cleanup in thermal makfile. > > Yangtao Li (11): > thermal: sun8i: add thermal driver for h6 > dt-bindings: thermal: add binding document for h6 thermal controller > thermal: fix indentation in makefile > thermal: sun8i: get ths sensor number from device compatible > thermal: sun8i: rework for sun8i_ths_get_temp() > thermal: sun8i: get ths init func from device compatible > thermal: sun8i: rework for ths irq handler func > thermal: sun8i: support ahb clocks > thermal: sun8i: rework for ths calibrate func > dt-bindings: thermal: add binding document for h3 thermal controller > thermal: sun8i: add thermal driver for h3 It would be nice to add dts changes to this series. It's unlikely that you'll get any "Tested-by" otherwise. > .../bindings/thermal/sun8i-thermal.yaml | 94 +++ > MAINTAINERS | 7 + > drivers/thermal/Kconfig | 14 + > drivers/thermal/Makefile | 9 +- > drivers/thermal/sun8i_thermal.c | 534 ++ > 5 files changed, 654 insertions(+), 4 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml > create mode 100644 drivers/thermal/sun8i_thermal.c > > --- > v4: > -add h3 support > -fix yaml file > --- > 2.17.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard wrote: > > On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote: > > > > Maybe instead of edp-connector one would introduce integrator's specific > > > > connector, for example with compatible "olimex,teres-edp-connector" > > > > which should follow edp abstract connector rules? This will be at least > > > > consistent with below presentation[1] - eDP requirements depends on > > > > integrator. Then if olimex has standard way of dealing with panels > > > > present in olimex/teres platforms the driver would then create > > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess. > > > > Anyway it still looks fishy for me :), maybe because I am not > > > > familiarized with details of these platforms. > > > > > > That makes sense yes > > > > Actually, it makes no sense at all. Current implementation for anx6345 > > driver works fine as is with any panel specified assuming panel delays > > are long enough for connected panel. It just doesn't use panel timings > > from the driver. Creating a platform driver for connector itself looks > > redundant since it can't be reused, it doesn't describe actual > > hardware and it's just defeats purpose of DT by introducing > > board-specific code. > > I'm not sure where you got the idea that the purpose of DT is to not > have any board-specific code. I believe DT was an attempt to move to declarative approach for describing hardware. Yes, we have different compatibles for different devices but they're specific to particular device rather than particular board. Device interconnection is described in DT along with some properties rather than in board-specific C-file. Introducing board-specific compatible for a connector isn't looking right to me. > It's perfectly fine to have some, that's even why there's a compatible > assigned to each and every board. > > What the DT is about is allowing us to have a generic behaviour that > we can detect: we can have a given behaviour for a given board, and a > separate one for another one, and this will be evaluated at runtime. > > This is *exactly* what this is about: we can have a compatible that > sets a given, more specific, behaviour (olimex,teres-edp-connector) > while saying that this is compatible with the generic behaviour > (edp-connector). That way, any OS will know what quirk to apply if > needed, and if not that it can use the generic behaviour. > > And we could create a generic driver, for the generic behaviour if > needed. > > > There's another issue: if we introduce edp-connector we'll have to > > specify power up delays somewhere (in dts? or in platform driver?), so > > edp-connector doesn't really solve the issue of multiple panels with > > same motherboard. > > And that's what that compatible is about :) Sorry, I fail to see how it would be different from using existing panels infrastructure and different panels compatibles. I think Rob's idea was to introduce generic edp-connector. If we can't make it generic then let's use panel infrastructure. > > I'd say DT overlays should be preferred solution here, not another > > connector binding. > > Overlays are a way to apply a device tree dynamically. It's orthogonal > to the binding. It isn't orthogonal to original problem though. > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
Re: [PATCH v2 7/7] arm64: defconfig: Enable Panfrost driver
On Fri, Jun 21, 2019 at 11:04 AM Krzysztof Kozlowski wrote: > > Enable support for Mali GPU with Panfrost driver, e.g. for Exynos5433 > and Exynos7 (having Mali T760). > > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm64/configs/defconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 6b4f5cf23324..972b17239f13 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -517,6 +517,7 @@ CONFIG_DRM_HISI_HIBMC=m > CONFIG_DRM_HISI_KIRIN=m > CONFIG_DRM_MESON=m > CONFIG_DRM_PL111=m > +CONFIG_DRM_PANFROST=m It makes sense to enable lima for arm64 defconfig as well since it's used on number of 64-bit Allwinner SoCs. > CONFIG_FB=y > CONFIG_FB_MODE_HELPERS=y > CONFIG_BACKLIGHT_GENERIC=m > @@ -717,7 +718,6 @@ CONFIG_ARCH_TEGRA_194_SOC=y > CONFIG_ARCH_K3_AM6_SOC=y > CONFIG_SOC_TI=y > CONFIG_TI_SCI_PM_DOMAINS=y > -CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND=y > CONFIG_EXTCON_USB_GPIO=y > CONFIG_EXTCON_USBC_CROS_EC=y > CONFIG_MEMORY=y > -- > 2.17.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v3 1/3] thermal: sun8i: add thermal driver for h6
On Wed, Jun 12, 2019 at 9:50 AM Frank Lee wrote: > > > If you have a git tree I'll be happy to contribute A64 support. IIRC > > it was quite similar to H3. > > I built a ths branch and I will do some work later. > > https://github.com/TinyWindzz/linux/tree/ths Looks like you forgot to add your patches to this branch.
Re: [PATCH] Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections"
Greg, Can we get this revert merged into stable branches? Bluetooth HID has been broken for many devices for quite a while now and RFC patch that fixes the breakage hasn't seen any movement for almost a month. Regards, Vasily On Thu, May 23, 2019 at 7:52 AM Vasily Khoruzhick wrote: > > On Wed, May 22, 2019 at 12:08 AM Marcel Holtmann wrote: > > > > Hi Vasily, > > > > >> This reverts commit d5bb334a8e171b262e48f378bd2096c0ea458265. > > >> > > >> This commit breaks some HID devices, see [1] for details > > >> > > >> https://bugzilla.kernel.org/show_bug.cgi?id=203643 > > >> > > >> Signed-off-by: Vasily Khoruzhick > > >> Cc: sta...@vger.kernel.org > > > > > > let me have a look at this. Maybe there is a missing initialization for > > > older HID devices that we need to handle. Do you happen to have the full > > > btmon binary trace from controller initialization to connection attempt > > > for me? > > > > > > Are both devices Bluetooth 2.1 or later device that are supporting Secure > > > Simple Pairing? Or is one of them a Bluetooth 2.0 or earlier device? > > > > I am almost certain that you have a Bluetooth 2.0 mouse. I made a really > > stupid mistake in the key size check logic and forgot to bind it to SSP > > support. Can you please check the patch that I just send you. > > > > https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-mar...@holtmann.org/T/#u > > This patch fixes the issue for me. Thanks! > > > > > Regards > > > > Marcel > >
Re: [PATCH v3 1/3] thermal: sun8i: add thermal driver for h6
On Mon, Jun 10, 2019 at 5:31 PM Frank Lee wrote: > > On Tue, Jun 11, 2019 at 7:29 AM Vasily Khoruzhick wrote: > > > > On Sat, May 25, 2019 at 11:17 AM Yangtao Li wrote: > > > > > > This patch adds the support for allwinner thermal sensor, within > > > allwinner SoC. It will register sensors for thermal framework > > > and use device tree to bind cooling device. > > > > Hi Yangtao, > > > > Any plans on v4 of this series? > > > > I am waiting for comment from Maxime. > > I’ll support both h3 and h6 in v4. If you have a git tree I'll be happy to contribute A64 support. IIRC it was quite similar to H3. > Yangtao
Re: [PATCH v3 1/3] thermal: sun8i: add thermal driver for h6
On Sat, May 25, 2019 at 11:17 AM Yangtao Li wrote:
>
> This patch adds the support for allwinner thermal sensor, within
> allwinner SoC. It will register sensors for thermal framework
> and use device tree to bind cooling device.
Hi Yangtao,
Any plans on v4 of this series?
> Signed-off-by: Yangtao Li
> ---
> MAINTAINERS | 7 +
> drivers/thermal/Kconfig | 14 +
> drivers/thermal/Makefile| 1 +
> drivers/thermal/sun8i_thermal.c | 437
> 4 files changed, 459 insertions(+)
> create mode 100644 drivers/thermal/sun8i_thermal.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2336dd26ece4..d312f9eecf0d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -674,6 +674,13 @@ L: linux-cry...@vger.kernel.org
> S: Maintained
> F: drivers/crypto/sunxi-ss/
>
> +ALLWINNER THERMAL DRIVER
> +M: Yangtao Li
> +L: linux...@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
> +F: drivers/thermal/sun8i_thermal.c
> +
> ALLWINNER VPU DRIVER
> M: Maxime Ripard
> M: Paul Kocialkowski
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 9966364a6deb..e5465053d66f 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -262,6 +262,20 @@ config SPEAR_THERMAL
> Enable this to plug the SPEAr thermal sensor driver into the Linux
> thermal framework.
>
> +config SUN8I_THERMAL
> + tristate "Allwinner sun8i thermal driver"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + depends on HAS_IOMEM
> + depends on NVMEM_SUNXI_SID
> + depends on OF
> + depends on RESET_CONTROLLER
> + help
> + Support for the sun8i thermal sensor driver into the Linux thermal
> + framework.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called sun8i-thermal.
> +
> config ROCKCHIP_THERMAL
> tristate "Rockchip thermal driver"
> depends on ARCH_ROCKCHIP || COMPILE_TEST
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 74a37c7f847a..fa6f8b206281 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -31,6 +31,7 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
> obj-y += broadcom/
> obj-$(CONFIG_THERMAL_MMIO) += thermal_mmio.o
> obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
> +obj-$(CONFIG_SUN8I_THERMAL) += sun8i_thermal.o
> obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
> obj-$(CONFIG_RCAR_GEN3_THERMAL)+= rcar_gen3_thermal.o
> diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> new file mode 100644
> index ..a9cc2197f4cb
> --- /dev/null
> +++ b/drivers/thermal/sun8i_thermal.c
> @@ -0,0 +1,437 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Thermal sensor driver for Allwinner SOC
> + * Copyright (C) 2019 Yangtao Li
> + *
> + * Based on the work of Icenowy Zheng
> + * Based on the work of Ondrej Jirman
> + * Based on the work of Josef Gajdusek
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX_SENSOR_NUM 4
> +
> +#define FT_TEMP_MASK GENMASK(11, 0)
> +#define TEMP_CALIB_MASKGENMASK(11, 0)
> +#define TEMP_TO_REG672
> +#define CALIBRATE_DEFAULT 0x800
> +
> +#define SUN50I_THS_CTRL0 0x00
> +#define SUN50I_H6_THS_ENABLE 0x04
> +#define SUN50I_H6_THS_PC 0x08
> +#define SUN50I_H6_THS_DIC 0x10
> +#define SUN50I_H6_THS_DIS 0x20
> +#define SUN50I_H6_THS_MFC 0x30
> +#define SUN50I_H6_THS_TEMP_CALIB 0xa0
> +#define SUN50I_H6_THS_TEMP_DATA0xc0
> +
> +#define SUN50I_THS_CTRL0_T_ACQ(x) ((GENMASK(15, 0) & (x)) << 16)
> +#define SUN50I_THS_FILTER_EN BIT(2)
> +#define SUN50I_THS_FILTER_TYPE(x) (GENMASK(1, 0) & (x))
> +#define SUN50I_H6_THS_PC_TEMP_PERIOD(x)((GENMASK(19, 0) &
> (x)) << 12)
> +#define SUN50I_H6_THS_DATA_IRQ_STS(x) BIT(x)
> +
> +/* millidegree celsius */
> +#define SUN50I_H6_FT_DEVIATION 7000
> +
> +struct ths_device;
> +
> +struct tsensor {
> + struct ths_device *tmdev;
> + struct thermal_zone_device *tzd;
> + int id;
> + wait_queue_head_t wait_queue;
> +};
> +
> +struct ths_thermal_chip {
> + int sensor_num;
> + int offset;
> + int scale;
> + int ft_deviation;
> +
Re: [PATCH 2/3] thermal: sun50i: add thermal driver for h6
On Sat, May 25, 2019 at 11:48 AM Frank Lee wrote:
>
> HI Ondřej,
>
> On Sun, May 19, 2019 at 10:22 PM Ondřej Jirman wrote:
> >
> > Hello Yangtao,
> >
> > On Sat, May 18, 2019 at 12:34:57AM +0800, Frank Lee wrote:
> > > HI,
> > >
> > > On Fri, May 17, 2019 at 2:29 AM Ondřej Jirman wrote:
> > > >
> > > > Hi Yangtao,
> > > >
> > > > thank you for work on this driver.
> > > >
> > > > On Fri, May 17, 2019 at 02:06:53AM +0800, Frank Lee wrote:
> > > > > HI Ondřej,
> > > > >
> > > > > On Mon, May 13, 2019 at 6:16 AM Ondřej Jirman
> > > > > wrote:
> > > > > > > +
> > > > > > > +/* Temp Unit: millidegree Celsius */
> > > > > > > +static int tsens_reg2temp(struct tsens_device *tmdev,
> > > > > > > + int reg)
> > > > > >
> > > > > > Please name all functions so that they are more clearly identifiable
> > > > > > in stack traces as belonging to this driver. For example:
> > > > > >
> > > > > > sun8i_ths_reg2temp
> > > > > >
> > > > > > The same applies for all tsens_* functions below. tsens_* is too
> > > > > > generic.
> > > > >
> > > > > Done but no sun8i_ths_reg2temp.
> > > > >
> > > > > ths_reg2tem() should be a generic func.
> > > > > I think it should be suitable for all platforms， so no platform
> > > > > prefix.
> > > >
> > > > You've missed my point. The driver name is sun8i_thermal and if you get
> > > > and oops from the kernel you'll get a stack trace where there are just
> > > > function
> > > > names. If you use too generic function names, it will not be clear which
> > > > driver is oopsing.
> > > >
> > > > - sun8i_ths_reg2temp will tell you much more clearly where to search
> > > > than
> > > > - ths_reg2temp
> > > >
> > > > Of course you can always grep, but most thermal drivers are thermal
> > > > sensor (ths)
> > > > drivers, and if multiple of them used this too-generic naming scheme
> > > > you'd
> > > > have hard time debugging.
> > > >
> > > > Look at other thermal drivers. They usually encode driver name in the
> > > > function
> > > > names to help with identification (even if these are static driver-local
> > > > functions).
> > > >
> > >
> > > Can we change to sunxi_ths_ prefix?
> >
> > It should probably match the driver name, but yes, that's better.
> >
> > > > > > > +static int tsens_probe(struct platform_device *pdev)
> > > > > > > +{
> > > > > > > + struct tsens_device *tmdev;
> > > > > > > + struct device *dev = >dev;
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + tmdev = devm_kzalloc(dev, sizeof(*tmdev), GFP_KERNEL);
> > > > > > > + if (!tmdev)
> > > > > > > + return -ENOMEM;
> > > > > > > +
> > > > > > > + tmdev->dev = dev;
> > > > > > > + tmdev->chip = of_device_get_match_data(>dev);
> > > > > > > + if (!tmdev->chip)
> > > > > > > + return -EINVAL;
> > > > > > > +
> > > > > > > + ret = tsens_init(tmdev);
> > > > > > > + if (ret)
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > + ret = tsens_register(tmdev);
> > > > > > > + if (ret)
> > > > > > > + return ret;
> > > > > >
> > > > > > Why split this out of probe into separate functions?
> > > > > >
> > > > > > > + ret = tmdev->chip->enable(tmdev);
> > > > > > > + if (ret)
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > + platform_set_drvdata(pdev, tmdev);
> > > > > > > +
> > > > > > > + return ret;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int tsens_remove(struct platform_device *pdev)
> > > > > > > +{
> > > > > > > + struct tsens_device *tmdev = platform_get_drvdata(pdev);
> > > > > > > +
> > > > > > > + tmdev->chip->disable(tmdev);
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > +static int sun50i_thermal_enable(struct tsens_device *tmdev)
> > > > > > > +{
> > > > > > > + int ret, val;
> > > > > > > +
> > > > > > > + ret = reset_control_deassert(tmdev->reset);
> > > > > > > + if (ret)
> > > > > > > + return ret;
> > > > > > > +
> > > > > > > + ret = clk_prepare_enable(tmdev->bus_clk);
> > > > > > > + if (ret)
> > > > > > > + goto assert_reset;
> > > > > > > +
> > > > > > > + ret = tsens_calibrate(tmdev);
> > > > > > > + if (ret)
> > > > > > > + return ret;
> > > > > >
> > > > > > If this fails (it may likely fail with EPROBE_DEFER) you are
> > > > > > leaving reset
> > > > > > deasserted, and clock enabled.
> > > > > >
> > > > > > Overall, I think, reset/clock management and nvmem reading will be
> > > > > > common
> > > > > > to all the HW variants, so it doesn't make much sense splitting it
> > > > > > out
> > > > > > of probe into separate functions, and makes it more error prone.
> > > > >
> > > > > Our long-term goal is to support all platforms.
> > > > > Bacicallt there is a differencr between each generation.
> > > > > So I feel it necessary to isolate these differences.
> > > > >
> > > > > Maybe:
> >
Re: [PATCH] Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections"
On Wed, May 22, 2019 at 12:08 AM Marcel Holtmann wrote: > > Hi Vasily, > > >> This reverts commit d5bb334a8e171b262e48f378bd2096c0ea458265. > >> > >> This commit breaks some HID devices, see [1] for details > >> > >> https://bugzilla.kernel.org/show_bug.cgi?id=203643 > >> > >> Signed-off-by: Vasily Khoruzhick > >> Cc: sta...@vger.kernel.org > > > > let me have a look at this. Maybe there is a missing initialization for > > older HID devices that we need to handle. Do you happen to have the full > > btmon binary trace from controller initialization to connection attempt for > > me? > > > > Are both devices Bluetooth 2.1 or later device that are supporting Secure > > Simple Pairing? Or is one of them a Bluetooth 2.0 or earlier device? > > I am almost certain that you have a Bluetooth 2.0 mouse. I made a really > stupid mistake in the key size check logic and forgot to bind it to SSP > support. Can you please check the patch that I just send you. > > https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-mar...@holtmann.org/T/#u This patch fixes the issue for me. Thanks! > > Regards > > Marcel >
[PATCH] Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections"
This reverts commit d5bb334a8e171b262e48f378bd2096c0ea458265.
This commit breaks some HID devices, see [1] for details
https://bugzilla.kernel.org/show_bug.cgi?id=203643
Signed-off-by: Vasily Khoruzhick
Cc: sta...@vger.kernel.org
---
include/net/bluetooth/hci_core.h | 3 ---
net/bluetooth/hci_conn.c | 8
2 files changed, 11 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 05b1b96f4d9e..094e61e07030 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -190,9 +190,6 @@ struct adv_info {
#define HCI_MAX_SHORT_NAME_LENGTH 10
-/* Min encryption key size to match with SMP */
-#define HCI_MIN_ENC_KEY_SIZE 7
-
/* Default LE RPA expiry time, 15 minutes */
#define HCI_DEFAULT_RPA_TIMEOUT(15 * 60)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 3cf0764d5793..bd4978ce8c45 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -1276,14 +1276,6 @@ int hci_conn_check_link_mode(struct hci_conn *conn)
!test_bit(HCI_CONN_ENCRYPT, >flags))
return 0;
- /* The minimum encryption key size needs to be enforced by the
-* host stack before establishing any L2CAP connections. The
-* specification in theory allows a minimum of 1, but to align
-* BR/EDR and LE transports, a minimum of 7 is chosen.
-*/
- if (conn->enc_key_size < HCI_MIN_ENC_KEY_SIZE)
- return 0;
-
return 1;
}
--
2.21.0
Re: [PATCH 2/3] thermal: sun50i: add thermal driver for h6
On Sun, May 12, 2019 at 6:39 AM Maxime Ripard wrote: > > Hi, > > Thanks a lot for working on this! > > On Sun, May 12, 2019 at 04:26:13AM -0400, Yangtao Li wrote: > > This patch adds the support for allwinner thermal sensor, within > > allwinner SoC. It will register sensors for thermal framework > > and use device tree to bind cooling device. > > > > Based on driver code found here: > > https://megous.com/git/linux and > > https://github.com/Allwinner-Homlet/H6-BSP4.9-linux > > I wouldn't place the URL in the commit log. The commit log stays > forever in the linux history. Git repos and branches are going away > over time. > > > Signed-off-by: Yangtao Li > > --- > > MAINTAINERS | 7 + > > drivers/thermal/Kconfig | 14 ++ > > drivers/thermal/Makefile | 1 + > > drivers/thermal/sun50i_thermal.c | 357 +++ > > The long term goal is to support all the thermal sensors, not just the > H6. Since that controller was introduced with the sun8i family, it > makes more sense to use that prefix for the driver and the functions. > > > 4 files changed, 379 insertions(+) > > create mode 100644 drivers/thermal/sun50i_thermal.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 3c65228e93c5..8da56582e72a 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -674,6 +674,13 @@ L: linux-cry...@vger.kernel.org > > S: Maintained > > F: drivers/crypto/sunxi-ss/ > > > > +ALLWINNER THERMAL DRIVER > > +M: Yangtao Li > > +L: linux...@vger.kernel.org > > +S: Maintained > > +F: Documentation/devicetree/bindings/thermal/sun50i-thermal.txt > > +F: drivers/thermal/sun50i_thermal.c > > + > > ALLWINNER VPU DRIVER > > M: Maxime Ripard > > M: Paul Kocialkowski > > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > > index 653aa27a25a4..2a8d1c98c6ca 100644 > > --- a/drivers/thermal/Kconfig > > +++ b/drivers/thermal/Kconfig > > @@ -252,6 +252,20 @@ config SPEAR_THERMAL > > Enable this to plug the SPEAr thermal sensor driver into the Linux > > thermal framework. > > > > +config SUN50I_THERMAL > > + tristate "Allwinner sun50i thermal driver" > > + depends on ARCH_SUNXI || COMPILE_TEST > > + depends on HAS_IOMEM > > + depends on NVMEM > > + depends on OF > > + depends on RESET_CONTROLLER > > + help > > + Support for the sun50i thermal sensor driver into the Linux thermal > > + framework. > > + > > + To compile this driver as a module, choose M here: the > > + module will be called sun50i-thermal. > > + > > config ROCKCHIP_THERMAL > > tristate "Rockchip thermal driver" > > depends on ARCH_ROCKCHIP || COMPILE_TEST > > diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile > > index 486d682be047..a09b30b90003 100644 > > --- a/drivers/thermal/Makefile > > +++ b/drivers/thermal/Makefile > > @@ -30,6 +30,7 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o > > # platform thermal drivers > > obj-y+= broadcom/ > > obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o > > +obj-$(CONFIG_SUN50I_THERMAL) += sun50i_thermal.o > > obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o > > obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o > > obj-$(CONFIG_RCAR_GEN3_THERMAL) += rcar_gen3_thermal.o > > diff --git a/drivers/thermal/sun50i_thermal.c > > b/drivers/thermal/sun50i_thermal.c > > new file mode 100644 > > index ..3bdb3677b3d4 > > --- /dev/null > > +++ b/drivers/thermal/sun50i_thermal.c > > @@ -0,0 +1,357 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Thermal sensor driver for Allwinner SOC > > + * Copyright (C) 2019 Yangtao Li > > + * > > + * Based on the work of Icenowy Zheng > > + * Based on the work of Ondrej Jirman > > + * Based on the work of Josef Gajdusek > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define MAX_SENSOR_NUM 4 > > + > > +#define FT_TEMP_MASK GENMASK(11, 0) > > +#define TEMP_CALIB_MASK GENMASK(11, 0) > > +#define TEMP_TO_REG 672 > > +#define CALIBRATE_DEFAULT0x800 > > + > > +#define SUN50I_THS_CTRL0 0x00 > > +#define SUN50I_H6_THS_ENABLE 0x04 > > +#define SUN50I_H6_THS_PC 0x08 > > +#define SUN50I_H6_THS_MFC0x30 > > +#define SUN50I_H6_TEMP_CALIB 0xa0 > > +#define SUN50I_H6_TEMP_DATA 0xc0 > > + > > +#define SUN50I_THS_CTRL0_T_ACQ(x)((GENMASK(15, 0) & (x)) << 16) > > +#define SUN50I_THS_FILTER_EN BIT(2) > > +#define SUN50I_THS_FILTER_TYPE(x)(GENMASK(1, 0) & (x)) > > +#define SUN50I_H6_THS_PC_TEMP_PERIOD(x) ((GENMASK(19, 0) & > > (x)) << 12) > > + > >
Re: [PATCH 0/9] Analogix ANX6345 RGB-(e)DP bridge support
On Mon, Feb 4, 2019 at 4:22 AM Torsten Duwe wrote: > > On Thu, Oct 18, 2018 at 03:33:18PM +0800, Icenowy Zheng wrote: > > This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge, > > which is used by some Allwinner A64 laptops, such as Pinebook and Olimex > > TERES-I. > > > > So what's the status here? I'm working on the Teres-I and I find myself > recreating the chunks in this patchset almost verbatim (only DT so far), > one by one, so there must be something right about them ;-) > > Whose turn is it? I've sent v2 yesterday, however I tested it only on Pinebook. > > Torsten > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: Applied "regulator: axp20x: fix ALDO2, DLDO2 and ELDO3 definitions for AXP803" to the regulator tree
Hey Mark,
Could you please apply it into your for-5.0 branch? It's a fix for a
regression and without this patch axp803 is broken in 5.0.
Regards,
Vasily
On Mon, Jan 28, 2019 at 4:35 AM Mark Brown wrote:
>
> The patch
>
>regulator: axp20x: fix ALDO2, DLDO2 and ELDO3 definitions for AXP803
>
> has been applied to the regulator tree at
>
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
>
> From 252d1c20551b745f33a490892335d2b09f5d48a7 Mon Sep 17 00:00:00 2001
> From: Vasily Khoruzhick
> Date: Fri, 25 Jan 2019 22:18:09 -0800
> Subject: [PATCH] regulator: axp20x: fix ALDO2, DLDO2 and ELDO3 definitions for
> AXP803
>
> Looks like refactoring didn't go well and left ALDO2, DLDO2 and ELDO3
> definitions broken for AXP803 - now they are using register address
> instead of mask. Fix it by using mask where necessary.
>
> Fixes: db4a555f7c4cf ("regulator: axp20x: use defines for masks")
> Signed-off-by: Vasily Khoruzhick
> Reviewed-by: Chen-Yu Tsai
> Signed-off-by: Mark Brown
> ---
> drivers/regulator/axp20x-regulator.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/regulator/axp20x-regulator.c
> b/drivers/regulator/axp20x-regulator.c
> index 0dfa4ea6bbdf..087cadb96fab 100644
> --- a/drivers/regulator/axp20x-regulator.c
> +++ b/drivers/regulator/axp20x-regulator.c
> @@ -723,7 +723,7 @@ static const struct regulator_desc axp803_regulators[] = {
> AXP22X_ALDO1_V_OUT, AXP22X_ALDO1_V_OUT_MASK,
> AXP22X_PWR_OUT_CTRL3, AXP806_PWR_OUT_ALDO1_MASK),
> AXP_DESC(AXP803, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
> -AXP22X_ALDO2_V_OUT, AXP22X_ALDO2_V_OUT,
> +AXP22X_ALDO2_V_OUT, AXP22X_ALDO2_V_OUT_MASK,
> AXP22X_PWR_OUT_CTRL3, AXP806_PWR_OUT_ALDO2_MASK),
> AXP_DESC(AXP803, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
> AXP22X_ALDO3_V_OUT, AXP22X_ALDO3_V_OUT_MASK,
> @@ -733,7 +733,7 @@ static const struct regulator_desc axp803_regulators[] = {
> AXP22X_PWR_OUT_CTRL2, AXP22X_PWR_OUT_DLDO1_MASK),
> AXP_DESC_RANGES(AXP803, DLDO2, "dldo2", "dldoin",
> axp803_dldo2_ranges, AXP803_DLDO2_NUM_VOLTAGES,
> - AXP22X_DLDO2_V_OUT, AXP22X_DLDO2_V_OUT,
> + AXP22X_DLDO2_V_OUT, AXP22X_DLDO2_V_OUT_MASK,
> AXP22X_PWR_OUT_CTRL2, AXP22X_PWR_OUT_DLDO2_MASK),
> AXP_DESC(AXP803, DLDO3, "dldo3", "dldoin", 700, 3300, 100,
> AXP22X_DLDO3_V_OUT, AXP22X_DLDO3_V_OUT_MASK,
> @@ -748,7 +748,7 @@ static const struct regulator_desc axp803_regulators[] = {
> AXP22X_ELDO2_V_OUT, AXP22X_ELDO2_V_OUT_MASK,
> AXP22X_PWR_OUT_CTRL2, AXP22X_PWR_OUT_ELDO2_MASK),
> AXP_DESC(AXP803, ELDO3, "eldo3", "eldoin", 700, 1900, 50,
> -AXP22X_ELDO3_V_OUT, AXP22X_ELDO3_V_OUT,
> +AXP22X_ELDO3_V_OUT, AXP22X_ELDO3_V_OUT_MASK,
> AXP22X_PWR_OUT_CTRL2, AXP22X_PWR_OUT_ELDO3_MASK),
> AXP_DESC(AXP803, FLDO1, "fldo1", "fldoin", 700, 1450, 50,
> AXP803_FLDO1_V_OUT, AXP803_FLDO1_V_OUT_MASK,
> --
> 2.20.1
>
Re: [PATCH 9/9] [DO NOT MERGE] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check
On Thu, Oct 18, 2018 at 4:31 AM Laurent Pinchart wrote: > Given that the tolerance is a property of the panel or bridge, I agree with > Daniel that it should be implemented there, or at least in cooperation with > drm_panel and drm_bridge. Clock tolerance is not specified in ANX6345 datasheet. > Semi-related information, I think the CEA and VESA standards allow a 0.5% > clock tolerance. What is the maximum clock frequency deviation required for > this platform ? This particular platform requires ~1% deviation. E.g. on Pinebook with 768p panel: requested clock: 73.0 MHz, real clock: 72.296296 MHz (0.96%) on Pinebook with 1080p panel: requested clock: 138.5 MHz, real clock: 138.461538 MHz (0.03%) So unfortunately 0.5% is not enough. Regards, Vasily
[PATCH] regulator: axp20x: fix ALDO2, DLDO2 and ELDO3 definitions for AXP803
Looks like refactoring didn't go well and left ALDO2, DLDO2 and ELDO3
definitions broken for AXP803 - now they are using register address
instead of mask. Fix it by using mask where necessary.
Fixes: db4a555f7c4cf ("regulator: axp20x: use defines for masks")
Signed-off-by: Vasily Khoruzhick
---
drivers/regulator/axp20x-regulator.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index 48af859fd053..a808b03cae10 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -719,7 +719,7 @@ static const struct regulator_desc axp803_regulators[] = {
AXP22X_ALDO1_V_OUT, AXP22X_ALDO1_V_OUT_MASK,
AXP22X_PWR_OUT_CTRL3, AXP806_PWR_OUT_ALDO1_MASK),
AXP_DESC(AXP803, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
-AXP22X_ALDO2_V_OUT, AXP22X_ALDO2_V_OUT,
+AXP22X_ALDO2_V_OUT, AXP22X_ALDO2_V_OUT_MASK,
AXP22X_PWR_OUT_CTRL3, AXP806_PWR_OUT_ALDO2_MASK),
AXP_DESC(AXP803, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
AXP22X_ALDO3_V_OUT, AXP22X_ALDO3_V_OUT_MASK,
@@ -729,7 +729,7 @@ static const struct regulator_desc axp803_regulators[] = {
AXP22X_PWR_OUT_CTRL2, AXP22X_PWR_OUT_DLDO1_MASK),
AXP_DESC_RANGES(AXP803, DLDO2, "dldo2", "dldoin",
axp803_dldo2_ranges, AXP803_DLDO2_NUM_VOLTAGES,
- AXP22X_DLDO2_V_OUT, AXP22X_DLDO2_V_OUT,
+ AXP22X_DLDO2_V_OUT, AXP22X_DLDO2_V_OUT_MASK,
AXP22X_PWR_OUT_CTRL2, AXP22X_PWR_OUT_DLDO2_MASK),
AXP_DESC(AXP803, DLDO3, "dldo3", "dldoin", 700, 3300, 100,
AXP22X_DLDO3_V_OUT, AXP22X_DLDO3_V_OUT_MASK,
@@ -744,7 +744,7 @@ static const struct regulator_desc axp803_regulators[] = {
AXP22X_ELDO2_V_OUT, AXP22X_ELDO2_V_OUT_MASK,
AXP22X_PWR_OUT_CTRL2, AXP22X_PWR_OUT_ELDO2_MASK),
AXP_DESC(AXP803, ELDO3, "eldo3", "eldoin", 700, 1900, 50,
-AXP22X_ELDO3_V_OUT, AXP22X_ELDO3_V_OUT,
+AXP22X_ELDO3_V_OUT, AXP22X_ELDO3_V_OUT_MASK,
AXP22X_PWR_OUT_CTRL2, AXP22X_PWR_OUT_ELDO3_MASK),
AXP_DESC(AXP803, FLDO1, "fldo1", "fldoin", 700, 1450, 50,
AXP803_FLDO1_V_OUT, AXP803_FLDO1_V_OUT_MASK,
--
2.20.1
Re: [PATCH v6 8/8] mfd: axp20x: Add supported cells for AXP803
On Fri, Dec 7, 2018 at 8:40 AM Lee Jones wrote: > My OCD-dar is going crazy. > > Why haven't you used the same alignment as is already there? > > If it starts to run over 80-chars then bring the others back. > > Also why is there a single liner shoved in the middle of the > multi-line entries? Please move the singles to the top or the > bottom. Hi Lee, Could you please reformat it in the way that makes your OCD-dar happy? It would be really nice to get AC and battery support for APX8x3 merged -- it'll make Pinebook and Teres-I pretty well supported by mainline kernel. Thanks, Vasily > > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v6 8/8] mfd: axp20x: Add supported cells for AXP803
On Fri, Dec 7, 2018 at 8:40 AM Lee Jones wrote: > My OCD-dar is going crazy. > > Why haven't you used the same alignment as is already there? > > If it starts to run over 80-chars then bring the others back. > > Also why is there a single liner shoved in the middle of the > multi-line entries? Please move the singles to the top or the > bottom. Hi Lee, Could you please reformat it in the way that makes your OCD-dar happy? It would be really nice to get AC and battery support for APX8x3 merged -- it'll make Pinebook and Teres-I pretty well supported by mainline kernel. Thanks, Vasily > > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v6 3/3] arm64: dts: allwinner: a64: enable sound on Pinebook
On Sat, Nov 17, 2018 at 8:02 AM Chen-Yu Tsai wrote:
>
> On Thu, Nov 15, 2018 at 1:48 PM Vasily Khoruzhick wrote:
> >
> > On Wed, Nov 7, 2018 at 11:30 PM Chen-Yu Tsai wrote:
> > > > +
> > > > + speaker_amp: speaker_amp {
> > > > + compatible = "simple-audio-amplifier";
> > > > + enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
> > >
> > > You might want to add a sound-name-prefix property. See
> > >
> > > Documentation/devicetree/bindings/sound/name-prefix.txt
> > >
> > > Also this should have a reference to its power supply regulator.
> >
> > You're right, it should reference its power supply which should be a
> > fixed regulator controlled via GPIO from AXP803.
> >
> > Unfortunately there's no AXP803 GPIO support yet and
> > simple-audio-amplifier doesn't have regulator property.
> >
> > I have no time (and interest) to work on it in near future, so if
> > anyone wants to pick it up - feel free to do so.
>
> Understood. I can try to pick it up when I have some extra time.
>
> On the other hand, I tried this series on my Pine64 and (with
> the necessary device tree changes) on my Bananapi M64. While
> audio played (did not stall), no audio was actually coming out
> of the headphones I had plugged in. I made sure that all needed
> mixer controls were enabled, and the DAPM graph read all green
> from the DAI to the Headphone jack.
>
> Any ideas?
Please show output of amixer. My guess is that you don't have 'AIF1
DAC' enabled.
>
> Regards
> ChenYu
Re: [PATCH v6 3/3] arm64: dts: allwinner: a64: enable sound on Pinebook
On Sat, Nov 17, 2018 at 8:02 AM Chen-Yu Tsai wrote:
>
> On Thu, Nov 15, 2018 at 1:48 PM Vasily Khoruzhick wrote:
> >
> > On Wed, Nov 7, 2018 at 11:30 PM Chen-Yu Tsai wrote:
> > > > +
> > > > + speaker_amp: speaker_amp {
> > > > + compatible = "simple-audio-amplifier";
> > > > + enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
> > >
> > > You might want to add a sound-name-prefix property. See
> > >
> > > Documentation/devicetree/bindings/sound/name-prefix.txt
> > >
> > > Also this should have a reference to its power supply regulator.
> >
> > You're right, it should reference its power supply which should be a
> > fixed regulator controlled via GPIO from AXP803.
> >
> > Unfortunately there's no AXP803 GPIO support yet and
> > simple-audio-amplifier doesn't have regulator property.
> >
> > I have no time (and interest) to work on it in near future, so if
> > anyone wants to pick it up - feel free to do so.
>
> Understood. I can try to pick it up when I have some extra time.
>
> On the other hand, I tried this series on my Pine64 and (with
> the necessary device tree changes) on my Bananapi M64. While
> audio played (did not stall), no audio was actually coming out
> of the headphones I had plugged in. I made sure that all needed
> mixer controls were enabled, and the DAPM graph read all green
> from the DAI to the Headphone jack.
>
> Any ideas?
Please show output of amixer. My guess is that you don't have 'AIF1
DAC' enabled.
>
> Regards
> ChenYu
Re: [PATCH v6 3/3] arm64: dts: allwinner: a64: enable sound on Pinebook
On Wed, Nov 7, 2018 at 11:30 PM Chen-Yu Tsai wrote:
> > +
> > + speaker_amp: speaker_amp {
> > + compatible = "simple-audio-amplifier";
> > + enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
>
> You might want to add a sound-name-prefix property. See
>
> Documentation/devicetree/bindings/sound/name-prefix.txt
>
> Also this should have a reference to its power supply regulator.
You're right, it should reference its power supply which should be a
fixed regulator controlled via GPIO from AXP803.
Unfortunately there's no AXP803 GPIO support yet and
simple-audio-amplifier doesn't have regulator property.
I have no time (and interest) to work on it in near future, so if
anyone wants to pick it up - feel free to do so.
Regards,
Vasily
Re: [PATCH v6 3/3] arm64: dts: allwinner: a64: enable sound on Pinebook
On Wed, Nov 7, 2018 at 11:30 PM Chen-Yu Tsai wrote:
> > +
> > + speaker_amp: speaker_amp {
> > + compatible = "simple-audio-amplifier";
> > + enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
>
> You might want to add a sound-name-prefix property. See
>
> Documentation/devicetree/bindings/sound/name-prefix.txt
>
> Also this should have a reference to its power supply regulator.
You're right, it should reference its power supply which should be a
fixed regulator controlled via GPIO from AXP803.
Unfortunately there's no AXP803 GPIO support yet and
simple-audio-amplifier doesn't have regulator property.
I have no time (and interest) to work on it in near future, so if
anyone wants to pick it up - feel free to do so.
Regards,
Vasily
Re: [PATCH v6 3/3] arm64: dts: allwinner: a64: enable sound on Pinebook
On Wed, Nov 7, 2018 at 11:30 PM Chen-Yu Tsai wrote:
>
> On Thu, Nov 8, 2018 at 2:42 PM Vasily Khoruzhick wrote:
> >
> > This commit enables I2S, digital and analog parts of audiocodec on
> > Pinebook
> >
> > Signed-off-by: Vasily Khoruzhick
> > ---
> > .../dts/allwinner/sun50i-a64-pinebook.dts | 42 +++
> > 1 file changed, 42 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > index 77fac84797e9..73f171f4ba9b 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > @@ -64,6 +64,23 @@
> > compatible = "mmc-pwrseq-simple";
> > reset-gpios = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> > };
> > +
> > + speaker_amp: speaker_amp {
> > + compatible = "simple-audio-amplifier";
> > + enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
>
> You might want to add a sound-name-prefix property. See
No need, there's only speaker amplifier in Pinebook.
>
> Documentation/devicetree/bindings/sound/name-prefix.txt
>
> Also this should have a reference to its power supply regulator.
It's powered from V5P0_USB according to schematics, which comes out of
5V BOOST USB HOST MODE POWER - and it's not controlled by software. So
there's nothing to reference.
>
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > +_analog {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > };
> >
> > {
> > @@ -267,6 +284,31 @@
> > vcc-hdmi-supply = <_dldo1>;
> > };
> >
> > + {
> > + status = "okay";
> > + simple-audio-card,widgets = "Microphone", "Internal Microphone
> > Left",
> > + "Microphone", "Internal Microphone
> > Right",
> > + "Headphone", "Headphone Jack",
> > + "Speaker", "Internal Speaker";
> > + simple-audio-card,aux-devs = <_analog>, <_amp>;
> > + simple-audio-card,routing =
> > + "Left DAC", "AIF1 Slot 0 Left",
> > + "Right DAC", "AIF1 Slot 0 Right",
> > + "INL", "LINEOUT",
> > + "INR", "LINEOUT",
> > + "Internal Speaker", "OUTL",
> > + "Internal Speaker", "OUTR",
> > + "Headphone Jack", "HP",
> > + "AIF1 Slot 0 Left ADC", "Left ADC",
> > + "AIF1 Slot 0 Right ADC", "Right ADC",
> > + "Left ADC", "ADC",
> > + "Right ADC", "ADC",
> > + "Internal Microphone Left", "MBIAS",
> > + "MIC1", "Internal Microphone Left",
> > + "Internal Microphone Right", "HBIAS",
> > + "MIC2", "Internal Microphone Right";
>
> The schematics is missing the actual jack, but this looks to be correct.
>
> ChenYu
>
> > +};
> > +
> > {
> > pinctrl-names = "default";
> > pinctrl-0 = <_pb_pins>;
> > --
> > 2.19.1
> >
Re: [PATCH v6 3/3] arm64: dts: allwinner: a64: enable sound on Pinebook
On Wed, Nov 7, 2018 at 11:30 PM Chen-Yu Tsai wrote:
>
> On Thu, Nov 8, 2018 at 2:42 PM Vasily Khoruzhick wrote:
> >
> > This commit enables I2S, digital and analog parts of audiocodec on
> > Pinebook
> >
> > Signed-off-by: Vasily Khoruzhick
> > ---
> > .../dts/allwinner/sun50i-a64-pinebook.dts | 42 +++
> > 1 file changed, 42 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > index 77fac84797e9..73f171f4ba9b 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> > @@ -64,6 +64,23 @@
> > compatible = "mmc-pwrseq-simple";
> > reset-gpios = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> > };
> > +
> > + speaker_amp: speaker_amp {
> > + compatible = "simple-audio-amplifier";
> > + enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
>
> You might want to add a sound-name-prefix property. See
No need, there's only speaker amplifier in Pinebook.
>
> Documentation/devicetree/bindings/sound/name-prefix.txt
>
> Also this should have a reference to its power supply regulator.
It's powered from V5P0_USB according to schematics, which comes out of
5V BOOST USB HOST MODE POWER - and it's not controlled by software. So
there's nothing to reference.
>
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > +_analog {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > };
> >
> > {
> > @@ -267,6 +284,31 @@
> > vcc-hdmi-supply = <_dldo1>;
> > };
> >
> > + {
> > + status = "okay";
> > + simple-audio-card,widgets = "Microphone", "Internal Microphone
> > Left",
> > + "Microphone", "Internal Microphone
> > Right",
> > + "Headphone", "Headphone Jack",
> > + "Speaker", "Internal Speaker";
> > + simple-audio-card,aux-devs = <_analog>, <_amp>;
> > + simple-audio-card,routing =
> > + "Left DAC", "AIF1 Slot 0 Left",
> > + "Right DAC", "AIF1 Slot 0 Right",
> > + "INL", "LINEOUT",
> > + "INR", "LINEOUT",
> > + "Internal Speaker", "OUTL",
> > + "Internal Speaker", "OUTR",
> > + "Headphone Jack", "HP",
> > + "AIF1 Slot 0 Left ADC", "Left ADC",
> > + "AIF1 Slot 0 Right ADC", "Right ADC",
> > + "Left ADC", "ADC",
> > + "Right ADC", "ADC",
> > + "Internal Microphone Left", "MBIAS",
> > + "MIC1", "Internal Microphone Left",
> > + "Internal Microphone Right", "HBIAS",
> > + "MIC2", "Internal Microphone Right";
>
> The schematics is missing the actual jack, but this looks to be correct.
>
> ChenYu
>
> > +};
> > +
> > {
> > pinctrl-names = "default";
> > pinctrl-0 = <_pb_pins>;
> > --
> > 2.19.1
> >
Re: [PATCH v6 2/3] arm64: dts: allwinner: a64: enable sound on Pine64 and SoPine
On Wed, Nov 7, 2018 at 11:11 PM Chen-Yu Tsai wrote:
>
> On Thu, Nov 8, 2018 at 2:42 PM Vasily Khoruzhick wrote:
> >
> > This commit enables I2S, digital and analog parts of audiocodec on
> > Pine64 and SoPine boards.
> >
> > Signed-off-by: Vasily Khoruzhick
> > ---
> > .../boot/dts/allwinner/sun50i-a64-pine64.dts | 28 +++
> > .../allwinner/sun50i-a64-sopine-baseboard.dts | 28 +++
> > 2 files changed, 56 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > index c077b6c1f458..ff352bdfbb93 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > @@ -75,6 +75,18 @@
> > };
> > };
> >
> > + {
> > + status = "okay";
> > +};
> > +
> > +_analog {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > {
> > status = "okay";
> > };
> > @@ -264,6 +276,22 @@
> > status = "disabled";
> > };
> >
> > + {
> > + status = "okay";
> > + simple-audio-card,widgets = "Microphone", "Microphone Jack",
> > + "Headphone", "Headphone Jack";
> > + simple-audio-card,routing =
> > + "Left DAC", "AIF1 Slot 0 Left",
> > + "Right DAC", "AIF1 Slot 0 Right",
> > + "Headphone Jack", "HP",
> > + "AIF1 Slot 0 Left ADC", "Left ADC",
> > + "AIF1 Slot 0 Right ADC", "Right ADC",
> > + "Left ADC", "ADC",
> > + "Right ADC", "ADC",
>
> As mentioned the above two don't belong in the device tree.
>
> > + "Microphone Jack", "HBIAS",
>
> Schematics says this is NC or not connected by default.
> You may want to ask Pine64 about this?
>
> Same comments for SoPine.
I'll just drop it. Not connected on schematics - we don't put it in dts.
>
> > + "MIC2", "Microphone Jack";
> > +};
> > +
> > /* On Exp and Euler connectors */
> > {
> > pinctrl-names = "default";
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> > index 53fcc9098df3..25d732df37c4 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> > @@ -80,6 +80,18 @@
> > };
> > };
> >
> > + {
> > + status = "okay";
> > +};
> > +
> > +_analog {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > {
> > status = "okay";
> > };
> > @@ -164,6 +176,22 @@
> > vcc-hdmi-supply = <_dldo1>;
> > };
> >
> > + {
> > + status = "okay";
> > + simple-audio-card,widgets = "Microphone", "Microphone Jack",
> > + "Headphone", "Headphone Jack";
> > + simple-audio-card,routing =
> > + "Left DAC", "AIF1 Slot 0 Left",
> > + "Right DAC", "AIF1 Slot 0 Right",
> > + "Headphone Jack", "HP",
> > + "AIF1 Slot 0 Left ADC", "Left ADC",
> > + "AIF1 Slot 0 Right ADC", "Right ADC",
> > + "Left ADC", "ADC",
> > + "Right ADC", "ADC",
> > + "Microphone Jack", "HBIAS",
> > + "MIC2", "Microphone Jack";
> > +};
> > +
> > {
> > pinctrl-names = "default";
> > pinctrl-0 = <_pb_pins>;
> > --
> > 2.19.1
> >
Re: [PATCH v6 2/3] arm64: dts: allwinner: a64: enable sound on Pine64 and SoPine
On Wed, Nov 7, 2018 at 11:11 PM Chen-Yu Tsai wrote:
>
> On Thu, Nov 8, 2018 at 2:42 PM Vasily Khoruzhick wrote:
> >
> > This commit enables I2S, digital and analog parts of audiocodec on
> > Pine64 and SoPine boards.
> >
> > Signed-off-by: Vasily Khoruzhick
> > ---
> > .../boot/dts/allwinner/sun50i-a64-pine64.dts | 28 +++
> > .../allwinner/sun50i-a64-sopine-baseboard.dts | 28 +++
> > 2 files changed, 56 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > index c077b6c1f458..ff352bdfbb93 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > @@ -75,6 +75,18 @@
> > };
> > };
> >
> > + {
> > + status = "okay";
> > +};
> > +
> > +_analog {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > {
> > status = "okay";
> > };
> > @@ -264,6 +276,22 @@
> > status = "disabled";
> > };
> >
> > + {
> > + status = "okay";
> > + simple-audio-card,widgets = "Microphone", "Microphone Jack",
> > + "Headphone", "Headphone Jack";
> > + simple-audio-card,routing =
> > + "Left DAC", "AIF1 Slot 0 Left",
> > + "Right DAC", "AIF1 Slot 0 Right",
> > + "Headphone Jack", "HP",
> > + "AIF1 Slot 0 Left ADC", "Left ADC",
> > + "AIF1 Slot 0 Right ADC", "Right ADC",
> > + "Left ADC", "ADC",
> > + "Right ADC", "ADC",
>
> As mentioned the above two don't belong in the device tree.
>
> > + "Microphone Jack", "HBIAS",
>
> Schematics says this is NC or not connected by default.
> You may want to ask Pine64 about this?
>
> Same comments for SoPine.
I'll just drop it. Not connected on schematics - we don't put it in dts.
>
> > + "MIC2", "Microphone Jack";
> > +};
> > +
> > /* On Exp and Euler connectors */
> > {
> > pinctrl-names = "default";
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> > index 53fcc9098df3..25d732df37c4 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
> > @@ -80,6 +80,18 @@
> > };
> > };
> >
> > + {
> > + status = "okay";
> > +};
> > +
> > +_analog {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > {
> > status = "okay";
> > };
> > @@ -164,6 +176,22 @@
> > vcc-hdmi-supply = <_dldo1>;
> > };
> >
> > + {
> > + status = "okay";
> > + simple-audio-card,widgets = "Microphone", "Microphone Jack",
> > + "Headphone", "Headphone Jack";
> > + simple-audio-card,routing =
> > + "Left DAC", "AIF1 Slot 0 Left",
> > + "Right DAC", "AIF1 Slot 0 Right",
> > + "Headphone Jack", "HP",
> > + "AIF1 Slot 0 Left ADC", "Left ADC",
> > + "AIF1 Slot 0 Right ADC", "Right ADC",
> > + "Left ADC", "ADC",
> > + "Right ADC", "ADC",
> > + "Microphone Jack", "HBIAS",
> > + "MIC2", "Microphone Jack";
> > +};
> > +
> > {
> > pinctrl-names = "default";
> > pinctrl-0 = <_pb_pins>;
> > --
> > 2.19.1
> >
[PATCH v6 1/3] arm64: dts: allwinner: a64: add nodes necessary for analog sound support
Add nodes for i2s, digital and analog parts of audiocodec on A64
Signed-off-by: Vasily Khoruzhick
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 58 +++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index f3a66f888205..53796a3e6bf3 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -173,6 +173,34 @@
compatible = "linux,spdif-dit";
};
+ sound: sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "sun50i-a64-audio";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <>;
+ simple-audio-card,bitclock-master = <>;
+ simple-audio-card,mclk-fs = <512>;
+ simple-audio-card,aux-devs = <_analog>;
+ simple-audio-card,routing =
+ "Left DAC", "AIF1 Slot 0 Left",
+ "Right DAC", "AIF1 Slot 0 Right",
+ "AIF1 Slot 0 Left ADC", "Left ADC",
+ "AIF1 Slot 0 Right ADC", "Right ADC",
+ "Left ADC", "ADC",
+ "Right ADC", "ADC",
+ "MIC1", "Mic",
+ "MIC2", "Headset Mic";
+ status = "disabled";
+
+ cpudai: simple-audio-card,cpu {
+ sound-dai = <>;
+ };
+
+ link_codec: simple-audio-card,codec {
+ sound-dai = <>;
+ };
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = ;
+ compatible = "allwinner,sun50i-a64-codec-i2s";
+ reg = <0x01c22c00 0x200>;
+ interrupts = ;
+ clocks = < CLK_BUS_CODEC>, < CLK_AC_DIG>;
+ clock-names = "apb", "mod";
+ resets = < RST_BUS_CODEC>;
+ reset-names = "rst";
+ dmas = < 15>, < 15>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
+ codec: codec@1c22e00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-a33-codec";
+ reg = <0x01c22e00 0x600>;
+ interrupts = ;
+ clocks = < CLK_BUS_CODEC>, < CLK_AC_DIG>;
+ clock-names = "bus", "mod";
+ status = "disabled";
+ };
+
uart0: serial@1c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
@@ -902,6 +954,12 @@
#reset-cells = <1>;
};
+ codec_analog: codec-analog@1f015c0 {
+ compatible = "allwinner,sun50i-a64-codec-analog";
+ reg = <0x01f015c0 0x4>;
+ status = "disabled";
+ };
+
r_i2c: i2c@1f02400 {
compatible = "allwinner,sun50i-a64-i2c",
"allwinner,sun6i-a31-i2c";
--
2.19.1
[PATCH v6 0/3] Add support for audiocodec in Allwinner A64
This series enables sound on Pine64, SoPine boards and Pinebook. v2: - Use simple-amplifier for speaker amp on Pinebook - Rename sun50i-a64-i2s to sun50i-a64-codec-i2s to preserve compatible string for other 3 I2S modules in A64 in case if there's any incompatibility with H3 v3: - renamed sunxi-adda-pr-regmap to sun8i-adda-pr-regmap - use ilog2() to calculate reg value for LRCK div instead of using a table v4: - dts: don't use 'Mic' and 'Headset Mic' widgets from sun8i-codec, define our board-level widgets instead. v5: - collect all the tags v6: - driver patches has been merged through ASoC tree - rebase onto 4.20-rc1 - Drop 'Speaker' from routes on sopine and pine64, they don't have speaker. Vasily Khoruzhick (3): arm64: dts: allwinner: a64: add nodes necessary for analog sound support arm64: dts: allwinner: a64: enable sound on Pine64 and SoPine arm64: dts: allwinner: a64: enable sound on Pinebook .../boot/dts/allwinner/sun50i-a64-pine64.dts | 28 + .../dts/allwinner/sun50i-a64-pinebook.dts | 42 ++ .../allwinner/sun50i-a64-sopine-baseboard.dts | 28 + arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 58 +++ 4 files changed, 156 insertions(+) -- 2.19.1
[PATCH v6 1/3] arm64: dts: allwinner: a64: add nodes necessary for analog sound support
Add nodes for i2s, digital and analog parts of audiocodec on A64
Signed-off-by: Vasily Khoruzhick
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 58 +++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index f3a66f888205..53796a3e6bf3 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -173,6 +173,34 @@
compatible = "linux,spdif-dit";
};
+ sound: sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "sun50i-a64-audio";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <>;
+ simple-audio-card,bitclock-master = <>;
+ simple-audio-card,mclk-fs = <512>;
+ simple-audio-card,aux-devs = <_analog>;
+ simple-audio-card,routing =
+ "Left DAC", "AIF1 Slot 0 Left",
+ "Right DAC", "AIF1 Slot 0 Right",
+ "AIF1 Slot 0 Left ADC", "Left ADC",
+ "AIF1 Slot 0 Right ADC", "Right ADC",
+ "Left ADC", "ADC",
+ "Right ADC", "ADC",
+ "MIC1", "Mic",
+ "MIC2", "Headset Mic";
+ status = "disabled";
+
+ cpudai: simple-audio-card,cpu {
+ sound-dai = <>;
+ };
+
+ link_codec: simple-audio-card,codec {
+ sound-dai = <>;
+ };
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = ;
+ compatible = "allwinner,sun50i-a64-codec-i2s";
+ reg = <0x01c22c00 0x200>;
+ interrupts = ;
+ clocks = < CLK_BUS_CODEC>, < CLK_AC_DIG>;
+ clock-names = "apb", "mod";
+ resets = < RST_BUS_CODEC>;
+ reset-names = "rst";
+ dmas = < 15>, < 15>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
+ codec: codec@1c22e00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-a33-codec";
+ reg = <0x01c22e00 0x600>;
+ interrupts = ;
+ clocks = < CLK_BUS_CODEC>, < CLK_AC_DIG>;
+ clock-names = "bus", "mod";
+ status = "disabled";
+ };
+
uart0: serial@1c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
@@ -902,6 +954,12 @@
#reset-cells = <1>;
};
+ codec_analog: codec-analog@1f015c0 {
+ compatible = "allwinner,sun50i-a64-codec-analog";
+ reg = <0x01f015c0 0x4>;
+ status = "disabled";
+ };
+
r_i2c: i2c@1f02400 {
compatible = "allwinner,sun50i-a64-i2c",
"allwinner,sun6i-a31-i2c";
--
2.19.1
[PATCH v6 0/3] Add support for audiocodec in Allwinner A64
This series enables sound on Pine64, SoPine boards and Pinebook. v2: - Use simple-amplifier for speaker amp on Pinebook - Rename sun50i-a64-i2s to sun50i-a64-codec-i2s to preserve compatible string for other 3 I2S modules in A64 in case if there's any incompatibility with H3 v3: - renamed sunxi-adda-pr-regmap to sun8i-adda-pr-regmap - use ilog2() to calculate reg value for LRCK div instead of using a table v4: - dts: don't use 'Mic' and 'Headset Mic' widgets from sun8i-codec, define our board-level widgets instead. v5: - collect all the tags v6: - driver patches has been merged through ASoC tree - rebase onto 4.20-rc1 - Drop 'Speaker' from routes on sopine and pine64, they don't have speaker. Vasily Khoruzhick (3): arm64: dts: allwinner: a64: add nodes necessary for analog sound support arm64: dts: allwinner: a64: enable sound on Pine64 and SoPine arm64: dts: allwinner: a64: enable sound on Pinebook .../boot/dts/allwinner/sun50i-a64-pine64.dts | 28 + .../dts/allwinner/sun50i-a64-pinebook.dts | 42 ++ .../allwinner/sun50i-a64-sopine-baseboard.dts | 28 + arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 58 +++ 4 files changed, 156 insertions(+) -- 2.19.1
[PATCH v6 3/3] arm64: dts: allwinner: a64: enable sound on Pinebook
This commit enables I2S, digital and analog parts of audiocodec on
Pinebook
Signed-off-by: Vasily Khoruzhick
---
.../dts/allwinner/sun50i-a64-pinebook.dts | 42 +++
1 file changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
index 77fac84797e9..73f171f4ba9b 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
@@ -64,6 +64,23 @@
compatible = "mmc-pwrseq-simple";
reset-gpios = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
};
+
+ speaker_amp: speaker_amp {
+ compatible = "simple-audio-amplifier";
+ enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+ };
+};
+
+ {
+ status = "okay";
+};
+
+_analog {
+ status = "okay";
+};
+
+ {
+ status = "okay";
};
{
@@ -267,6 +284,31 @@
vcc-hdmi-supply = <_dldo1>;
};
+ {
+ status = "okay";
+ simple-audio-card,widgets = "Microphone", "Internal Microphone Left",
+ "Microphone", "Internal Microphone Right",
+ "Headphone", "Headphone Jack",
+ "Speaker", "Internal Speaker";
+ simple-audio-card,aux-devs = <_analog>, <_amp>;
+ simple-audio-card,routing =
+ "Left DAC", "AIF1 Slot 0 Left",
+ "Right DAC", "AIF1 Slot 0 Right",
+ "INL", "LINEOUT",
+ "INR", "LINEOUT",
+ "Internal Speaker", "OUTL",
+ "Internal Speaker", "OUTR",
+ "Headphone Jack", "HP",
+ "AIF1 Slot 0 Left ADC", "Left ADC",
+ "AIF1 Slot 0 Right ADC", "Right ADC",
+ "Left ADC", "ADC",
+ "Right ADC", "ADC",
+ "Internal Microphone Left", "MBIAS",
+ "MIC1", "Internal Microphone Left",
+ "Internal Microphone Right", "HBIAS",
+ "MIC2", "Internal Microphone Right";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pb_pins>;
--
2.19.1
[PATCH v6 2/3] arm64: dts: allwinner: a64: enable sound on Pine64 and SoPine
This commit enables I2S, digital and analog parts of audiocodec on
Pine64 and SoPine boards.
Signed-off-by: Vasily Khoruzhick
---
.../boot/dts/allwinner/sun50i-a64-pine64.dts | 28 +++
.../allwinner/sun50i-a64-sopine-baseboard.dts | 28 +++
2 files changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index c077b6c1f458..ff352bdfbb93 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -75,6 +75,18 @@
};
};
+ {
+ status = "okay";
+};
+
+_analog {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
@@ -264,6 +276,22 @@
status = "disabled";
};
+ {
+ status = "okay";
+ simple-audio-card,widgets = "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack";
+ simple-audio-card,routing =
+ "Left DAC", "AIF1 Slot 0 Left",
+ "Right DAC", "AIF1 Slot 0 Right",
+ "Headphone Jack", "HP",
+ "AIF1 Slot 0 Left ADC", "Left ADC",
+ "AIF1 Slot 0 Right ADC", "Right ADC",
+ "Left ADC", "ADC",
+ "Right ADC", "ADC",
+ "Microphone Jack", "HBIAS",
+ "MIC2", "Microphone Jack";
+};
+
/* On Exp and Euler connectors */
{
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
index 53fcc9098df3..25d732df37c4 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
@@ -80,6 +80,18 @@
};
};
+ {
+ status = "okay";
+};
+
+_analog {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
@@ -164,6 +176,22 @@
vcc-hdmi-supply = <_dldo1>;
};
+ {
+ status = "okay";
+ simple-audio-card,widgets = "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack";
+ simple-audio-card,routing =
+ "Left DAC", "AIF1 Slot 0 Left",
+ "Right DAC", "AIF1 Slot 0 Right",
+ "Headphone Jack", "HP",
+ "AIF1 Slot 0 Left ADC", "Left ADC",
+ "AIF1 Slot 0 Right ADC", "Right ADC",
+ "Left ADC", "ADC",
+ "Right ADC", "ADC",
+ "Microphone Jack", "HBIAS",
+ "MIC2", "Microphone Jack";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pb_pins>;
--
2.19.1
[PATCH v6 3/3] arm64: dts: allwinner: a64: enable sound on Pinebook
This commit enables I2S, digital and analog parts of audiocodec on
Pinebook
Signed-off-by: Vasily Khoruzhick
---
.../dts/allwinner/sun50i-a64-pinebook.dts | 42 +++
1 file changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
index 77fac84797e9..73f171f4ba9b 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
@@ -64,6 +64,23 @@
compatible = "mmc-pwrseq-simple";
reset-gpios = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
};
+
+ speaker_amp: speaker_amp {
+ compatible = "simple-audio-amplifier";
+ enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+ };
+};
+
+ {
+ status = "okay";
+};
+
+_analog {
+ status = "okay";
+};
+
+ {
+ status = "okay";
};
{
@@ -267,6 +284,31 @@
vcc-hdmi-supply = <_dldo1>;
};
+ {
+ status = "okay";
+ simple-audio-card,widgets = "Microphone", "Internal Microphone Left",
+ "Microphone", "Internal Microphone Right",
+ "Headphone", "Headphone Jack",
+ "Speaker", "Internal Speaker";
+ simple-audio-card,aux-devs = <_analog>, <_amp>;
+ simple-audio-card,routing =
+ "Left DAC", "AIF1 Slot 0 Left",
+ "Right DAC", "AIF1 Slot 0 Right",
+ "INL", "LINEOUT",
+ "INR", "LINEOUT",
+ "Internal Speaker", "OUTL",
+ "Internal Speaker", "OUTR",
+ "Headphone Jack", "HP",
+ "AIF1 Slot 0 Left ADC", "Left ADC",
+ "AIF1 Slot 0 Right ADC", "Right ADC",
+ "Left ADC", "ADC",
+ "Right ADC", "ADC",
+ "Internal Microphone Left", "MBIAS",
+ "MIC1", "Internal Microphone Left",
+ "Internal Microphone Right", "HBIAS",
+ "MIC2", "Internal Microphone Right";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pb_pins>;
--
2.19.1
[PATCH v6 2/3] arm64: dts: allwinner: a64: enable sound on Pine64 and SoPine
This commit enables I2S, digital and analog parts of audiocodec on
Pine64 and SoPine boards.
Signed-off-by: Vasily Khoruzhick
---
.../boot/dts/allwinner/sun50i-a64-pine64.dts | 28 +++
.../allwinner/sun50i-a64-sopine-baseboard.dts | 28 +++
2 files changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index c077b6c1f458..ff352bdfbb93 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -75,6 +75,18 @@
};
};
+ {
+ status = "okay";
+};
+
+_analog {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
@@ -264,6 +276,22 @@
status = "disabled";
};
+ {
+ status = "okay";
+ simple-audio-card,widgets = "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack";
+ simple-audio-card,routing =
+ "Left DAC", "AIF1 Slot 0 Left",
+ "Right DAC", "AIF1 Slot 0 Right",
+ "Headphone Jack", "HP",
+ "AIF1 Slot 0 Left ADC", "Left ADC",
+ "AIF1 Slot 0 Right ADC", "Right ADC",
+ "Left ADC", "ADC",
+ "Right ADC", "ADC",
+ "Microphone Jack", "HBIAS",
+ "MIC2", "Microphone Jack";
+};
+
/* On Exp and Euler connectors */
{
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
index 53fcc9098df3..25d732df37c4 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
@@ -80,6 +80,18 @@
};
};
+ {
+ status = "okay";
+};
+
+_analog {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
status = "okay";
};
@@ -164,6 +176,22 @@
vcc-hdmi-supply = <_dldo1>;
};
+ {
+ status = "okay";
+ simple-audio-card,widgets = "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack";
+ simple-audio-card,routing =
+ "Left DAC", "AIF1 Slot 0 Left",
+ "Right DAC", "AIF1 Slot 0 Right",
+ "Headphone Jack", "HP",
+ "AIF1 Slot 0 Left ADC", "Left ADC",
+ "AIF1 Slot 0 Right ADC", "Right ADC",
+ "Left ADC", "ADC",
+ "Right ADC", "ADC",
+ "Microphone Jack", "HBIAS",
+ "MIC2", "Microphone Jack";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pb_pins>;
--
2.19.1
Re: [PATCH] ASoC: sunxi: rename SND_SUN8I_ADDA_PR_REGMAP
On Fri, Nov 2, 2018 at 3:04 PM Arnd Bergmann wrote: > > On 11/2/18, Vasily Khoruzhick wrote: > > On Friday, November 2, 2018 8:33:40 AM PDT Arnd Bergmann wrote: > >> The newly added SND_SUN50I_CODEC_ANALOG driver selects a nonexisting > >> symbol SND_SUNXI_ADDA_PR_REGMAP, which was evidently intended to replace > >> SND_SUN8I_ADDA_PR_REGMAP, but since they are now mismatched, we can run > >> into link errors for some configurations: > >> > >> sound/soc/sunxi/sun50i-codec-analog.o: In function > >> `sun50i_codec_analog_probe': sun50i-codec-analog.c:(.text+0x62): > >> undefined > >> reference to `sun8i_adda_pr_regmap_init' > >> > >> The new name appears to be more sensible, and as the symbol is hidden, > >> there are no downsides in the rename, so use that consistently now. > > > > Maxime asked it to be SND_SUN8I_ADDA_PR_REGMAP, and also it would be easier > > to > > fix it my renaming last remaining SND_SUNXI_ADDA_PR_REGMAP to > > SND_SUN8I_ADDA_PR_REGMAP. > > Sure, I don't care either way. Please send a patch to do that then. Will do tonight. > > Arnd
Re: [PATCH] ASoC: sunxi: rename SND_SUN8I_ADDA_PR_REGMAP
On Fri, Nov 2, 2018 at 3:04 PM Arnd Bergmann wrote: > > On 11/2/18, Vasily Khoruzhick wrote: > > On Friday, November 2, 2018 8:33:40 AM PDT Arnd Bergmann wrote: > >> The newly added SND_SUN50I_CODEC_ANALOG driver selects a nonexisting > >> symbol SND_SUNXI_ADDA_PR_REGMAP, which was evidently intended to replace > >> SND_SUN8I_ADDA_PR_REGMAP, but since they are now mismatched, we can run > >> into link errors for some configurations: > >> > >> sound/soc/sunxi/sun50i-codec-analog.o: In function > >> `sun50i_codec_analog_probe': sun50i-codec-analog.c:(.text+0x62): > >> undefined > >> reference to `sun8i_adda_pr_regmap_init' > >> > >> The new name appears to be more sensible, and as the symbol is hidden, > >> there are no downsides in the rename, so use that consistently now. > > > > Maxime asked it to be SND_SUN8I_ADDA_PR_REGMAP, and also it would be easier > > to > > fix it my renaming last remaining SND_SUNXI_ADDA_PR_REGMAP to > > SND_SUN8I_ADDA_PR_REGMAP. > > Sure, I don't care either way. Please send a patch to do that then. Will do tonight. > > Arnd
Re: [PATCH] ASoC: sunxi: rename SND_SUN8I_ADDA_PR_REGMAP
On Friday, November 2, 2018 8:33:40 AM PDT Arnd Bergmann wrote:
> The newly added SND_SUN50I_CODEC_ANALOG driver selects a nonexisting
> symbol SND_SUNXI_ADDA_PR_REGMAP, which was evidently intended to replace
> SND_SUN8I_ADDA_PR_REGMAP, but since they are now mismatched, we can run
> into link errors for some configurations:
>
> sound/soc/sunxi/sun50i-codec-analog.o: In function
> `sun50i_codec_analog_probe': sun50i-codec-analog.c:(.text+0x62): undefined
> reference to `sun8i_adda_pr_regmap_init'
>
> The new name appears to be more sensible, and as the symbol is hidden,
> there are no downsides in the rename, so use that consistently now.
Maxime asked it to be SND_SUN8I_ADDA_PR_REGMAP, and also it would be easier to
fix it my renaming last remaining SND_SUNXI_ADDA_PR_REGMAP to
SND_SUN8I_ADDA_PR_REGMAP.
> Fixes: 42371f327df0 ("ASoC: sunxi: Add new driver for Allwinner A64 codec's
> analog path controls") Signed-off-by: Arnd Bergmann
> ---
> sound/soc/sunxi/Kconfig | 4 ++--
> sound/soc/sunxi/Makefile | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
> index 66aad0d3f9c7..0f992bdf1a10 100644
> --- a/sound/soc/sunxi/Kconfig
> +++ b/sound/soc/sunxi/Kconfig
> @@ -23,7 +23,7 @@ config SND_SUN8I_CODEC
> config SND_SUN8I_CODEC_ANALOG
> tristate "Allwinner sun8i Codec Analog Controls Support"
> depends on MACH_SUN8I || (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> - select SND_SUN8I_ADDA_PR_REGMAP
> + select SND_SUNXI_ADDA_PR_REGMAP
> help
> Say Y or M if you want to add support for the analog controls for
> the codec embedded in newer Allwinner SoCs.
> @@ -54,7 +54,7 @@ config SND_SUN4I_SPDIF
> Say Y or M to add support for the S/PDIF audio block in the Allwinner
> A10 and affiliated SoCs.
>
> -config SND_SUN8I_ADDA_PR_REGMAP
> +config SND_SUNXI_ADDA_PR_REGMAP
> tristate
> select REGMAP
>
> diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
> index a86be340a076..c4dd2803a011 100644
> --- a/sound/soc/sunxi/Makefile
> +++ b/sound/soc/sunxi/Makefile
> @@ -5,4 +5,4 @@ obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
> obj-$(CONFIG_SND_SUN8I_CODEC_ANALOG) += sun8i-codec-analog.o
> obj-$(CONFIG_SND_SUN50I_CODEC_ANALOG) += sun50i-codec-analog.o
> obj-$(CONFIG_SND_SUN8I_CODEC) += sun8i-codec.o
> -obj-$(CONFIG_SND_SUN8I_ADDA_PR_REGMAP) += sun8i-adda-pr-regmap.o
> +obj-$(CONFIG_SND_SUNXI_ADDA_PR_REGMAP) += sun8i-adda-pr-regmap.o
Re: [PATCH] ASoC: sunxi: rename SND_SUN8I_ADDA_PR_REGMAP
On Friday, November 2, 2018 8:33:40 AM PDT Arnd Bergmann wrote:
> The newly added SND_SUN50I_CODEC_ANALOG driver selects a nonexisting
> symbol SND_SUNXI_ADDA_PR_REGMAP, which was evidently intended to replace
> SND_SUN8I_ADDA_PR_REGMAP, but since they are now mismatched, we can run
> into link errors for some configurations:
>
> sound/soc/sunxi/sun50i-codec-analog.o: In function
> `sun50i_codec_analog_probe': sun50i-codec-analog.c:(.text+0x62): undefined
> reference to `sun8i_adda_pr_regmap_init'
>
> The new name appears to be more sensible, and as the symbol is hidden,
> there are no downsides in the rename, so use that consistently now.
Maxime asked it to be SND_SUN8I_ADDA_PR_REGMAP, and also it would be easier to
fix it my renaming last remaining SND_SUNXI_ADDA_PR_REGMAP to
SND_SUN8I_ADDA_PR_REGMAP.
> Fixes: 42371f327df0 ("ASoC: sunxi: Add new driver for Allwinner A64 codec's
> analog path controls") Signed-off-by: Arnd Bergmann
> ---
> sound/soc/sunxi/Kconfig | 4 ++--
> sound/soc/sunxi/Makefile | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
> index 66aad0d3f9c7..0f992bdf1a10 100644
> --- a/sound/soc/sunxi/Kconfig
> +++ b/sound/soc/sunxi/Kconfig
> @@ -23,7 +23,7 @@ config SND_SUN8I_CODEC
> config SND_SUN8I_CODEC_ANALOG
> tristate "Allwinner sun8i Codec Analog Controls Support"
> depends on MACH_SUN8I || (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> - select SND_SUN8I_ADDA_PR_REGMAP
> + select SND_SUNXI_ADDA_PR_REGMAP
> help
> Say Y or M if you want to add support for the analog controls for
> the codec embedded in newer Allwinner SoCs.
> @@ -54,7 +54,7 @@ config SND_SUN4I_SPDIF
> Say Y or M to add support for the S/PDIF audio block in the Allwinner
> A10 and affiliated SoCs.
>
> -config SND_SUN8I_ADDA_PR_REGMAP
> +config SND_SUNXI_ADDA_PR_REGMAP
> tristate
> select REGMAP
>
> diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
> index a86be340a076..c4dd2803a011 100644
> --- a/sound/soc/sunxi/Makefile
> +++ b/sound/soc/sunxi/Makefile
> @@ -5,4 +5,4 @@ obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
> obj-$(CONFIG_SND_SUN8I_CODEC_ANALOG) += sun8i-codec-analog.o
> obj-$(CONFIG_SND_SUN50I_CODEC_ANALOG) += sun50i-codec-analog.o
> obj-$(CONFIG_SND_SUN8I_CODEC) += sun8i-codec.o
> -obj-$(CONFIG_SND_SUN8I_ADDA_PR_REGMAP) += sun8i-adda-pr-regmap.o
> +obj-$(CONFIG_SND_SUNXI_ADDA_PR_REGMAP) += sun8i-adda-pr-regmap.o
Re: [PATCH 0/9] Analogix ANX6345 RGB-(e)DP bridge support
On Thu, Oct 18, 2018 at 12:35 AM Icenowy Zheng wrote:
>
> This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge,
> which is used by some Allwinner A64 laptops, such as Pinebook and Olimex
> TERES-I.
>
> It reuses some definitions from the ANX78xx driver that already exists
> in the kernel tree, but the driver code itself is rewritten, because the
> big difference between ANX6345 and ANX78xx.
>
> This patchset also enables the bridge on Pinebook and TERES-I, and a
> temporary workaround patch (do not merge) for the dot clock accuracy
> problem of sun4i-drm.
>
> This patchset assumes some fixes ([1], [2] and [3]) are already
> applied, without them the patchset cannot be tested on the A64 devices
> mentioned above.
For whole series:
Tested-by: Vasily Khoruzhick
>
> [1] https://patchwork.kernel.org/patch/10628827/
> [2] https://patchwork.kernel.org/patch/10628825/
> [3] https://patchwork.kernel.org/patch/10646791/
>
> Chen-Yu Tsai (1):
> [DO NOT MERGE] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency
> check
>
> Icenowy Zheng (8):
> drm/bridge: move ANA78xx driver to analogix subdirectory
> drm/bridge: split some definitions of ANX78xx to dedicated headers
> drm/bridge: extract some Analogix I2C DP common code
> dt-bindings: Add ANX6345 DP/eDP transmitter binding
> drm/bridge: Add Analogix anx6345 support
> arm64: allwinner: a64: add pinmux for RGB666 LCD
> arm64: allwinner: a64: enable ANX6345 bridge on Pinebook
> arm64: allwinner: a64: enable ANX6345 bridge on TERES-I
>
> .../bindings/display/bridge/anx6345.txt | 39 +
> .../dts/allwinner/sun50i-a64-pinebook.dts | 43 +
> .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 40 +-
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +
> drivers/gpu/drm/bridge/Kconfig| 10 -
> drivers/gpu/drm/bridge/Makefile | 4 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.h | 719 ---
> drivers/gpu/drm/bridge/analogix/Kconfig | 25 +
> drivers/gpu/drm/bridge/analogix/Makefile | 4 +
> .../drm/bridge/analogix/analogix-anx6345.c| 862 ++
> .../bridge/{ => analogix}/analogix-anx78xx.c | 146 +--
> .../drm/bridge/analogix/analogix-anx78xx.h| 265 ++
> .../drm/bridge/analogix/analogix-i2c-dptx.c | 169
> .../drm/bridge/analogix/analogix-i2c-dptx.h | 258 ++
> .../bridge/analogix/analogix-i2c-txcommon.h | 240 +
> drivers/gpu/drm/sun4i/sun4i_rgb.c | 5 +-
> 16 files changed, 1956 insertions(+), 882 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/anx6345.txt
> delete mode 100644 drivers/gpu/drm/bridge/analogix-anx78xx.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c (90%)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
>
> --
> 2.18.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 0/9] Analogix ANX6345 RGB-(e)DP bridge support
On Thu, Oct 18, 2018 at 12:35 AM Icenowy Zheng wrote:
>
> This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge,
> which is used by some Allwinner A64 laptops, such as Pinebook and Olimex
> TERES-I.
>
> It reuses some definitions from the ANX78xx driver that already exists
> in the kernel tree, but the driver code itself is rewritten, because the
> big difference between ANX6345 and ANX78xx.
>
> This patchset also enables the bridge on Pinebook and TERES-I, and a
> temporary workaround patch (do not merge) for the dot clock accuracy
> problem of sun4i-drm.
>
> This patchset assumes some fixes ([1], [2] and [3]) are already
> applied, without them the patchset cannot be tested on the A64 devices
> mentioned above.
For whole series:
Tested-by: Vasily Khoruzhick
>
> [1] https://patchwork.kernel.org/patch/10628827/
> [2] https://patchwork.kernel.org/patch/10628825/
> [3] https://patchwork.kernel.org/patch/10646791/
>
> Chen-Yu Tsai (1):
> [DO NOT MERGE] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency
> check
>
> Icenowy Zheng (8):
> drm/bridge: move ANA78xx driver to analogix subdirectory
> drm/bridge: split some definitions of ANX78xx to dedicated headers
> drm/bridge: extract some Analogix I2C DP common code
> dt-bindings: Add ANX6345 DP/eDP transmitter binding
> drm/bridge: Add Analogix anx6345 support
> arm64: allwinner: a64: add pinmux for RGB666 LCD
> arm64: allwinner: a64: enable ANX6345 bridge on Pinebook
> arm64: allwinner: a64: enable ANX6345 bridge on TERES-I
>
> .../bindings/display/bridge/anx6345.txt | 39 +
> .../dts/allwinner/sun50i-a64-pinebook.dts | 43 +
> .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 40 +-
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +
> drivers/gpu/drm/bridge/Kconfig| 10 -
> drivers/gpu/drm/bridge/Makefile | 4 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.h | 719 ---
> drivers/gpu/drm/bridge/analogix/Kconfig | 25 +
> drivers/gpu/drm/bridge/analogix/Makefile | 4 +
> .../drm/bridge/analogix/analogix-anx6345.c| 862 ++
> .../bridge/{ => analogix}/analogix-anx78xx.c | 146 +--
> .../drm/bridge/analogix/analogix-anx78xx.h| 265 ++
> .../drm/bridge/analogix/analogix-i2c-dptx.c | 169
> .../drm/bridge/analogix/analogix-i2c-dptx.h | 258 ++
> .../bridge/analogix/analogix-i2c-txcommon.h | 240 +
> drivers/gpu/drm/sun4i/sun4i_rgb.c | 5 +-
> 16 files changed, 1956 insertions(+), 882 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/anx6345.txt
> delete mode 100644 drivers/gpu/drm/bridge/analogix-anx78xx.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> rename drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c (90%)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
>
> --
> 2.18.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v4 0/7] AXP8x3 AC and battery power supply support
On Saturday, October 13, 2018 1:08:41 AM PDT Oskari Lemmela wrote: > AXP813 AC power supply support with input current and > voltage limiting support. > > AXP803 AC and battery power supply support. > > Changes in v4: > * Change order of axp20x-gpio in axp20x.c > * Fix indentation and spaces to tabs in axp20x.c > > Changes in v3: > * Reorder ac_power_supply DT node > * Rename axp20x_ac_power_set_property function > * Split mfd commit > > Changes in v2: > * Reuse axp813 compatibles for axp803 > * Refactor axp20x_ac_power.c Patches 1-3, 5-7: Tested-by: Vasily Khoruzhick > Oskari Lemmela (7): > dt-bindings: power: supply: axp20x: add AXP813 AC power DT binding > ARM: dts: axp81x: add AC power supply subnode > arm64: dts: allwinner: axp803: add AC and battery power supplies > arm64: dts: allwinner: a64: sopine: enable power supplies > power: supply: add AC power supply driver for AXP813 > mfd: axp20x: Add AC power supply cell for AXP813 > mfd: axp20x: Add supported cells for AXP803 > > .../bindings/power/supply/axp20x_ac_power.txt | 3 + > arch/arm/boot/dts/axp81x.dtsi | 5 + > arch/arm64/boot/dts/allwinner/axp803.dtsi | 31 +++ > .../allwinner/sun50i-a64-sopine-baseboard.dts | 8 ++ > drivers/mfd/axp20x.c | 20 > drivers/power/supply/axp20x_ac_power.c| 92 +++ > include/linux/mfd/axp20x.h| 1 + > 7 files changed, 160 insertions(+)
Re: [PATCH v4 0/7] AXP8x3 AC and battery power supply support
On Saturday, October 13, 2018 1:08:41 AM PDT Oskari Lemmela wrote: > AXP813 AC power supply support with input current and > voltage limiting support. > > AXP803 AC and battery power supply support. > > Changes in v4: > * Change order of axp20x-gpio in axp20x.c > * Fix indentation and spaces to tabs in axp20x.c > > Changes in v3: > * Reorder ac_power_supply DT node > * Rename axp20x_ac_power_set_property function > * Split mfd commit > > Changes in v2: > * Reuse axp813 compatibles for axp803 > * Refactor axp20x_ac_power.c Patches 1-3, 5-7: Tested-by: Vasily Khoruzhick > Oskari Lemmela (7): > dt-bindings: power: supply: axp20x: add AXP813 AC power DT binding > ARM: dts: axp81x: add AC power supply subnode > arm64: dts: allwinner: axp803: add AC and battery power supplies > arm64: dts: allwinner: a64: sopine: enable power supplies > power: supply: add AC power supply driver for AXP813 > mfd: axp20x: Add AC power supply cell for AXP813 > mfd: axp20x: Add supported cells for AXP803 > > .../bindings/power/supply/axp20x_ac_power.txt | 3 + > arch/arm/boot/dts/axp81x.dtsi | 5 + > arch/arm64/boot/dts/allwinner/axp803.dtsi | 31 +++ > .../allwinner/sun50i-a64-sopine-baseboard.dts | 8 ++ > drivers/mfd/axp20x.c | 20 > drivers/power/supply/axp20x_ac_power.c| 92 +++ > include/linux/mfd/axp20x.h| 1 + > 7 files changed, 160 insertions(+)
[PATCH v3] neighbour: confirm neigh entries when ARP packet is received
Update 'confirmed' timestamp when ARP packet is received. It shouldn't
affect locktime logic and anyway entry can be confirmed by any higher-layer
protocol. Thus it makes sense to confirm it when ARP packet is received.
Fixes: 77d7123342 ("neighbour: update neigh timestamps iff update is effective")
Signed-off-by: Vasily Khoruzhick
---
v2: - update comment to match new code.
v3: - fix wording in commit message, make 'Fixes' tag one line, remove extra
new line
between 'Fixes' and 'Signed-off-by'.
net/core/neighbour.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index aa19d86937af..91592fceeaad 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1180,6 +1180,12 @@ int neigh_update(struct neighbour *neigh, const u8
*lladdr, u8 new,
lladdr = neigh->ha;
}
+ /* Update confirmed timestamp for neighbour entry after we
+* received ARP packet even if it doesn't change IP to MAC binding.
+*/
+ if (new & NUD_CONNECTED)
+ neigh->confirmed = jiffies;
+
/* If entry was valid and address is not changed,
do not change entry state, if new one is STALE.
*/
@@ -1201,15 +1207,12 @@ int neigh_update(struct neighbour *neigh, const u8
*lladdr, u8 new,
}
}
- /* Update timestamps only once we know we will make a change to the
+ /* Update timestamp only once we know we will make a change to the
* neighbour entry. Otherwise we risk to move the locktime window with
* noop updates and ignore relevant ARP updates.
*/
- if (new != old || lladdr != neigh->ha) {
- if (new & NUD_CONNECTED)
- neigh->confirmed = jiffies;
+ if (new != old || lladdr != neigh->ha)
neigh->updated = jiffies;
- }
if (new != old) {
neigh_del_timer(neigh);
--
2.18.0
[PATCH v3] neighbour: confirm neigh entries when ARP packet is received
Update 'confirmed' timestamp when ARP packet is received. It shouldn't
affect locktime logic and anyway entry can be confirmed by any higher-layer
protocol. Thus it makes sense to confirm it when ARP packet is received.
Fixes: 77d7123342 ("neighbour: update neigh timestamps iff update is effective")
Signed-off-by: Vasily Khoruzhick
---
v2: - update comment to match new code.
v3: - fix wording in commit message, make 'Fixes' tag one line, remove extra
new line
between 'Fixes' and 'Signed-off-by'.
net/core/neighbour.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index aa19d86937af..91592fceeaad 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1180,6 +1180,12 @@ int neigh_update(struct neighbour *neigh, const u8
*lladdr, u8 new,
lladdr = neigh->ha;
}
+ /* Update confirmed timestamp for neighbour entry after we
+* received ARP packet even if it doesn't change IP to MAC binding.
+*/
+ if (new & NUD_CONNECTED)
+ neigh->confirmed = jiffies;
+
/* If entry was valid and address is not changed,
do not change entry state, if new one is STALE.
*/
@@ -1201,15 +1207,12 @@ int neigh_update(struct neighbour *neigh, const u8
*lladdr, u8 new,
}
}
- /* Update timestamps only once we know we will make a change to the
+ /* Update timestamp only once we know we will make a change to the
* neighbour entry. Otherwise we risk to move the locktime window with
* noop updates and ignore relevant ARP updates.
*/
- if (new != old || lladdr != neigh->ha) {
- if (new & NUD_CONNECTED)
- neigh->confirmed = jiffies;
+ if (new != old || lladdr != neigh->ha)
neigh->updated = jiffies;
- }
if (new != old) {
neigh_del_timer(neigh);
--
2.18.0
Re: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1
On Mon, Feb 16, 2015 at 7:54 PM, Robert Jarzmik wrote: > Oh, do you volunteer ? That would indeed ease up my burden. I only rebased > pxa3xx_nand, so any help to submit and push is welcome. At least I can commit > to > review, and I would concentrate on pxa_camera.c in the meantime. I can rebase those patches on-top of Linus' tree and make sure they work on my machine. I can test pxamci, pxa2xx-spi and pxa2xx-pcm drivers. But I don't think that I have enough time now to submit it and go through review process. Btw, where I can find your git tree? Regards, Vasily > Cheers. > > -- > Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1
On Sun, Feb 15, 2015 at 1:47 AM, Robert Jarzmik wrote: > In order to slowly transition pxa to dmaengine, the legacy code will now > rely on dmaengine to request a channel. Hi Robert, What about dropping old PXA DMA code completely? Daniel Mack did port for most of PXA drivers to dma engine, I've rebased his patches against 3.17 several months ago and fixed oopses in pxamci and asoc drivers, but I didn't resubmit whole series due to lack of time. My 3.17 tree is at [1], I've tested it on pxa270 machine (Zipit Z2), and everything works fine so far. I guess it won't be too much work to rebase it against linux-3.20. Regards, Vasily [1] https://github.com/anarsoul/linux-2.6/tree/v3.17-pxa-dmaengine-wip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1
On Mon, Feb 16, 2015 at 7:54 PM, Robert Jarzmik robert.jarz...@free.fr wrote: Oh, do you volunteer ? That would indeed ease up my burden. I only rebased pxa3xx_nand, so any help to submit and push is welcome. At least I can commit to review, and I would concentrate on pxa_camera.c in the meantime. I can rebase those patches on-top of Linus' tree and make sure they work on my machine. I can test pxamci, pxa2xx-spi and pxa2xx-pcm drivers. But I don't think that I have enough time now to submit it and go through review process. Btw, where I can find your git tree? Regards, Vasily Cheers. -- Robert -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1
On Sun, Feb 15, 2015 at 1:47 AM, Robert Jarzmik robert.jarz...@free.fr wrote: In order to slowly transition pxa to dmaengine, the legacy code will now rely on dmaengine to request a channel. Hi Robert, What about dropping old PXA DMA code completely? Daniel Mack did port for most of PXA drivers to dma engine, I've rebased his patches against 3.17 several months ago and fixed oopses in pxamci and asoc drivers, but I didn't resubmit whole series due to lack of time. My 3.17 tree is at [1], I've tested it on pxa270 machine (Zipit Z2), and everything works fine so far. I guess it won't be too much work to rebase it against linux-3.20. Regards, Vasily [1] https://github.com/anarsoul/linux-2.6/tree/v3.17-pxa-dmaengine-wip -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: gadget: udc: s3c2410_udc.c: Remove some unused functions
On Sun, Dec 21, 2014 at 1:30 AM, Rickard Strandqvist
wrote:
> Removes some functions that are not used anywhere:
> s3c2410_udc_clear_ep_state() s3c2410_udc_set_ep0_sse_out()
>
> This was partially found by using a static code analysis program called
> cppcheck.
Looks OK to me.
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/usb/gadget/udc/s3c2410_udc.c | 20
> 1 file changed, 20 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/s3c2410_udc.c
> b/drivers/usb/gadget/udc/s3c2410_udc.c
> index ff423d1..41b60cd 100644
> --- a/drivers/usb/gadget/udc/s3c2410_udc.c
> +++ b/drivers/usb/gadget/udc/s3c2410_udc.c
> @@ -238,14 +238,6 @@ static inline void s3c2410_udc_set_ep0_de_out(void
> __iomem *base)
> S3C2410_UDC_EP0_CSR_REG);
> }
>
> -static inline void s3c2410_udc_set_ep0_sse_out(void __iomem *base)
> -{
> - udc_writeb(base, S3C2410_UDC_INDEX_EP0, S3C2410_UDC_INDEX_REG);
> - udc_writeb(base, (S3C2410_UDC_EP0_CSR_SOPKTRDY
> - | S3C2410_UDC_EP0_CSR_SSE),
> - S3C2410_UDC_EP0_CSR_REG);
> -}
> -
> static inline void s3c2410_udc_set_ep0_de_in(void __iomem *base)
> {
> udc_writeb(base, S3C2410_UDC_INDEX_EP0, S3C2410_UDC_INDEX_REG);
> @@ -291,18 +283,6 @@ static void s3c2410_udc_nuke(struct s3c2410_udc *udc,
> }
> }
>
> -static inline void s3c2410_udc_clear_ep_state(struct s3c2410_udc *dev)
> -{
> - unsigned i;
> -
> - /* hardware SET_{CONFIGURATION,INTERFACE} automagic resets endpoint
> -* fifos, and pending transactions mustn't be continued in any case.
> -*/
> -
> - for (i = 1; i < S3C2410_ENDPOINTS; i++)
> - s3c2410_udc_nuke(dev, >ep[i], -ECONNABORTED);
> -}
> -
> static inline int s3c2410_udc_fifo_count_out(void)
> {
> int tmp;
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: gadget: udc: s3c2410_udc.c: Remove some unused functions
On Sun, Dec 21, 2014 at 1:30 AM, Rickard Strandqvist
rickard_strandqv...@spectrumdigital.se wrote:
Removes some functions that are not used anywhere:
s3c2410_udc_clear_ep_state() s3c2410_udc_set_ep0_sse_out()
This was partially found by using a static code analysis program called
cppcheck.
Looks OK to me.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
drivers/usb/gadget/udc/s3c2410_udc.c | 20
1 file changed, 20 deletions(-)
diff --git a/drivers/usb/gadget/udc/s3c2410_udc.c
b/drivers/usb/gadget/udc/s3c2410_udc.c
index ff423d1..41b60cd 100644
--- a/drivers/usb/gadget/udc/s3c2410_udc.c
+++ b/drivers/usb/gadget/udc/s3c2410_udc.c
@@ -238,14 +238,6 @@ static inline void s3c2410_udc_set_ep0_de_out(void
__iomem *base)
S3C2410_UDC_EP0_CSR_REG);
}
-static inline void s3c2410_udc_set_ep0_sse_out(void __iomem *base)
-{
- udc_writeb(base, S3C2410_UDC_INDEX_EP0, S3C2410_UDC_INDEX_REG);
- udc_writeb(base, (S3C2410_UDC_EP0_CSR_SOPKTRDY
- | S3C2410_UDC_EP0_CSR_SSE),
- S3C2410_UDC_EP0_CSR_REG);
-}
-
static inline void s3c2410_udc_set_ep0_de_in(void __iomem *base)
{
udc_writeb(base, S3C2410_UDC_INDEX_EP0, S3C2410_UDC_INDEX_REG);
@@ -291,18 +283,6 @@ static void s3c2410_udc_nuke(struct s3c2410_udc *udc,
}
}
-static inline void s3c2410_udc_clear_ep_state(struct s3c2410_udc *dev)
-{
- unsigned i;
-
- /* hardware SET_{CONFIGURATION,INTERFACE} automagic resets endpoint
-* fifos, and pending transactions mustn't be continued in any case.
-*/
-
- for (i = 1; i S3C2410_ENDPOINTS; i++)
- s3c2410_udc_nuke(dev, dev-ep[i], -ECONNABORTED);
-}
-
static inline int s3c2410_udc_fifo_count_out(void)
{
int tmp;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH CFT] ARM:S3C24XX: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default
On Fri, Dec 13, 2013 at 2:28 PM, panchaxari
wrote:
> Configs ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR are enabled as default
> to platform S3C24XX.
>
> Introduction of PHYS_VIRT config as default would enable phy-to-virt and
> virt-to-phy translation function at boot and module loading time
> and enforce dynamic reallocation of memory. AUTO_ZRELADDR config would
> enable calculation of kernel load address at run time.
>
> PHYS_VIRT config is mutually exclusive to XIP_KERNEL, XIP_KERNEL is used in
> systems with NOR flash devices, and ZRELADDR config is mutually exclusive
> to ZBOOT_ROM.
>
> CFT::Call For Testing
>
> Requesting maintainers of S3C24XX platforms to evaluate the changes on the
> board and comment, as I dont have the board for testing and also requesting
> an ACK the changes.
Hi,
I guess AUTO_ZRELADDR will break S2RAM on h1940/rx1950 and rx3715
machines. Those machines require reservation of 4k at 0x30003000 and
4k at 0x30081000, because bootloader
will corrupt these areas on resume. See .reserve callback in
arch/arm/mach-s3c24xx/mach-{h1940,rx1950,rx3715}
Regards
Vasily
>
> Signed-off-by: panchaxari
> Cc: Heiko Stuebner
> Cc: Ben Dooks
> Cc: Kukjin Kim
> Cc: Russell King
> Cc: Linus Walleij
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
> S3C24XX is basically a Samsung SOC with ARM920T instruction set, and has
> an operating frquency of 203MHz, it also has enhanced MMU architecture
> to support WinCE, EPOC 32 and Linux.
>
> This SOC is an Integrated system for hand-held devices and general
> embedded systems.
>
> Supports various types of ROM for booting (NOR/NAND Flash, EEPROM, and
> others).
> Supports 8 memory banks, 128M for each bank, with a total of 1GB.
> ---
> arch/arm/Kconfig |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 32acacb..ec1faea 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -708,6 +708,8 @@ config ARCH_S3C24XX
> bool "Samsung S3C24XX SoCs"
> select ARCH_HAS_CPUFREQ
> select ARCH_REQUIRE_GPIOLIB
> + select ARM_PATCH_PHYS_VIRT
> + select AUTO_ZRELADDR
> select CLKDEV_LOOKUP
> select CLKSRC_SAMSUNG_PWM
> select GENERIC_CLOCKEVENTS
> --
> 1.7.10.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH CFT] ARM:S3C24XX: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default
On Fri, Dec 13, 2013 at 2:28 PM, panchaxari
panchaxari.prasannamur...@linaro.org wrote:
Configs ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR are enabled as default
to platform S3C24XX.
Introduction of PHYS_VIRT config as default would enable phy-to-virt and
virt-to-phy translation function at boot and module loading time
and enforce dynamic reallocation of memory. AUTO_ZRELADDR config would
enable calculation of kernel load address at run time.
PHYS_VIRT config is mutually exclusive to XIP_KERNEL, XIP_KERNEL is used in
systems with NOR flash devices, and ZRELADDR config is mutually exclusive
to ZBOOT_ROM.
CFT::Call For Testing
Requesting maintainers of S3C24XX platforms to evaluate the changes on the
board and comment, as I dont have the board for testing and also requesting
an ACK the changes.
Hi,
I guess AUTO_ZRELADDR will break S2RAM on h1940/rx1950 and rx3715
machines. Those machines require reservation of 4k at 0x30003000 and
4k at 0x30081000, because bootloader
will corrupt these areas on resume. See .reserve callback in
arch/arm/mach-s3c24xx/mach-{h1940,rx1950,rx3715}
Regards
Vasily
Signed-off-by: panchaxari panchaxari.prasannamur...@linaro.org
Cc: Heiko Stuebner he...@sntech.de
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
S3C24XX is basically a Samsung SOC with ARM920T instruction set, and has
an operating frquency of 203MHz, it also has enhanced MMU architecture
to support WinCE, EPOC 32 and Linux.
This SOC is an Integrated system for hand-held devices and general
embedded systems.
Supports various types of ROM for booting (NOR/NAND Flash, EEPROM, and
others).
Supports 8 memory banks, 128M for each bank, with a total of 1GB.
---
arch/arm/Kconfig |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 32acacb..ec1faea 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -708,6 +708,8 @@ config ARCH_S3C24XX
bool Samsung S3C24XX SoCs
select ARCH_HAS_CPUFREQ
select ARCH_REQUIRE_GPIOLIB
+ select ARM_PATCH_PHYS_VIRT
+ select AUTO_ZRELADDR
select CLKDEV_LOOKUP
select CLKSRC_SAMSUNG_PWM
select GENERIC_CLOCKEVENTS
--
1.7.10.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Tue, Dec 10, 2013 at 3:43 PM, Linus Walleij wrote:
> On Fri, Dec 6, 2013 at 5:48 PM, Sergei Ianovich wrote:
>
>> ICP DAS calls LP-8x4x 'programmable automation controller'. It is
>> an industrial computer based on PXA270 SoC. They ship it with a 2.6.19
>> kernel and proprietary kernel module and userspace library to access
>> its industrial IO.
>
> OK... so we only have device tree support for PXA3xx and noone is
> working on PXA2xx. And now we pile up some more legacy code.
> Such is life. But this:
>
>> +static unsigned long lp8x4x_pin_config[] = {
>> + /* MMC */
>> + GPIO32_MMC_CLK,
>> + GPIO112_MMC_CMD,
>> + GPIO92_MMC_DAT_0,
>> + GPIO109_MMC_DAT_1,
>> + GPIO110_MMC_DAT_2,
>> + GPIO111_MMC_DAT_3,
>> +
>> + /* USB Host Port 1 */
>> + GPIO88_USBH1_PWR,
>> + GPIO89_USBH1_PEN,
>> +};
>
> (...)
>> +static void __init lp8x4x_init(void)
>> +{
>> + pxa2xx_mfp_config(ARRAY_AND_SIZE(lp8x4x_pin_config));
> (...)
>
> Argh! Now you're adding another user for a legacy custom pin control
> implementation. But if noone is going to modernize PXA2xx what
> can we do :-/
I tried a ~year ago, but it's not so trivial. PXA2xx has no separate
pin control module, it's
highly integrated into GPIO controller. I've asked the maillist what
should I do for that case, but AFAIR no one answered.
Regards
Vasily
> Yours,
> Linus Walleij
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/11] arm: pxa27x: support ICP DAS LP-8x4x
On Tue, Dec 10, 2013 at 3:43 PM, Linus Walleij linus.wall...@linaro.org wrote:
On Fri, Dec 6, 2013 at 5:48 PM, Sergei Ianovich ynv...@gmail.com wrote:
ICP DAS calls LP-8x4x 'programmable automation controller'. It is
an industrial computer based on PXA270 SoC. They ship it with a 2.6.19
kernel and proprietary kernel module and userspace library to access
its industrial IO.
OK... so we only have device tree support for PXA3xx and noone is
working on PXA2xx. And now we pile up some more legacy code.
Such is life. But this:
+static unsigned long lp8x4x_pin_config[] = {
+ /* MMC */
+ GPIO32_MMC_CLK,
+ GPIO112_MMC_CMD,
+ GPIO92_MMC_DAT_0,
+ GPIO109_MMC_DAT_1,
+ GPIO110_MMC_DAT_2,
+ GPIO111_MMC_DAT_3,
+
+ /* USB Host Port 1 */
+ GPIO88_USBH1_PWR,
+ GPIO89_USBH1_PEN,
+};
(...)
+static void __init lp8x4x_init(void)
+{
+ pxa2xx_mfp_config(ARRAY_AND_SIZE(lp8x4x_pin_config));
(...)
Argh! Now you're adding another user for a legacy custom pin control
implementation. But if noone is going to modernize PXA2xx what
can we do :-/
I tried a ~year ago, but it's not so trivial. PXA2xx has no separate
pin control module, it's
highly integrated into GPIO controller. I've asked the maillist what
should I do for that case, but AFAIR no one answered.
Regards
Vasily
Yours,
Linus Walleij
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] leds: Add generic support for memory mapped LEDs
On Thu, Nov 1, 2012 at 8:58 PM, Pawel Moll wrote:
> LEDs are often controlled by writing to memory mapped
> register. This patch adds:
>
> 1. Generic functions for platform code and drivers to create
>class device for LEDs controlled by arbitrary bit masks.
>The control register value is read, modified by logic AND
>and OR operations with respective mask and written back.
>
> 2. A platform driver for simple use case when one or more LED
>are controlled by consecutive bits in a register pointed
>at by the platform device's memory resource. It can be
>particularly useful for MFD cells being part of an other
>device.
Hi
This MMIO controls some latch (or whatever) which is actually GPIO.
So implementing generic GPIO MMIO driver and using leds-gpio on top of
it appears to be a better solution for me.
Regards
Vasily
> Signed-off-by: Pawel Moll
> ---
> drivers/leds/Kconfig |8 ++
> drivers/leds/Makefile|1 +
> drivers/leds/leds-mmio.c | 250
> ++
> include/linux/leds.h | 38 +++
> 4 files changed, 297 insertions(+)
> create mode 100644 drivers/leds/leds-mmio.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index f508def..93707e6 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -457,6 +457,14 @@ config LEDS_BLINKM
> This option enables support for the BlinkM RGB LED connected
> through I2C. Say Y to enable support for the BlinkM LED.
>
> +config LEDS_MMIO
> + tristate "Generic LED support for memory mapped peripherals"
> + depends on LEDS_CLASS
> + depends on HAS_IOMEM
> + help
> + This option enables generic support for LEDs controlled via
> + memory mapped registers.
> +
> config LEDS_TRIGGERS
> bool "LED Trigger support"
> depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 3fb9641..8e5d0c8 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_LEDS_RENESAS_TPU)+=
> leds-renesas-tpu.o
> obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o
> obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
> obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
> +obj-$(CONFIG_LEDS_MMIO)+= leds-mmio.o
>
> # LED SPI Drivers
> obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
> diff --git a/drivers/leds/leds-mmio.c b/drivers/leds/leds-mmio.c
> new file mode 100644
> index 000..1ef0cda
> --- /dev/null
> +++ b/drivers/leds/leds-mmio.c
> @@ -0,0 +1,250 @@
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Copyright (C) 2012 ARM Limited
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +
> +static u32 mmio_led_read(void __iomem *reg, unsigned reg_size)
> +{
> + switch (reg_size) {
> + case 32:
> + return readl(reg);
> + case 16:
> + return readw(reg);
> + case 8:
> + return readb(reg);
> + }
> + return 0;
> +}
> +
> +static void mmio_led_write(void __iomem *reg, unsigned reg_size, u32 val)
> +{
> + switch (reg_size) {
> + case 32:
> + writel(val, reg);
> + return;
> + case 16:
> + writew(val, reg);
> + return;
> + case 8:
> + writeb(val, reg);
> + return;
> + }
> +}
> +
> +
> +struct mmio_led {
> + struct led_classdev cdev;
> + spinlock_t *lock;
> + void __iomem *reg;
> + unsigned reg_size;
> + u32 off_and_mask, off_or_mask;
> + u32 on_and_mask, on_or_mask;
> +};
> +
> +static void mmio_led_brightness_set(struct led_classdev *cdev,
> + enum led_brightness brightness)
> +{
> + struct mmio_led *led = container_of(cdev, struct mmio_led, cdev);
> + unsigned long uninitialized_var(flags);
> + u32 val;
> +
> + if (led->lock)
> + spin_lock_irqsave(led->lock, flags);
> +
> + val = mmio_led_read(led->reg, led->reg_size);
> + if (brightness == LED_OFF) {
> + val &= led->off_and_mask;
> + val |= led->off_or_mask;
> + } else {
> + val &= led->on_and_mask;
> + val |= led->on_or_mask;
> + }
> + mmio_led_write(led->reg, led->reg_size, val);
> +
> + if (led->lock)
> + spin_unlock_irqrestore(led->lock, flags);
>
Re: [PATCH 1/2] leds: Add generic support for memory mapped LEDs
On Thu, Nov 1, 2012 at 8:58 PM, Pawel Moll pawel.m...@arm.com wrote:
LEDs are often controlled by writing to memory mapped
register. This patch adds:
1. Generic functions for platform code and drivers to create
class device for LEDs controlled by arbitrary bit masks.
The control register value is read, modified by logic AND
and OR operations with respective mask and written back.
2. A platform driver for simple use case when one or more LED
are controlled by consecutive bits in a register pointed
at by the platform device's memory resource. It can be
particularly useful for MFD cells being part of an other
device.
Hi
This MMIO controls some latch (or whatever) which is actually GPIO.
So implementing generic GPIO MMIO driver and using leds-gpio on top of
it appears to be a better solution for me.
Regards
Vasily
Signed-off-by: Pawel Moll pawel.m...@arm.com
---
drivers/leds/Kconfig |8 ++
drivers/leds/Makefile|1 +
drivers/leds/leds-mmio.c | 250
++
include/linux/leds.h | 38 +++
4 files changed, 297 insertions(+)
create mode 100644 drivers/leds/leds-mmio.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index f508def..93707e6 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -457,6 +457,14 @@ config LEDS_BLINKM
This option enables support for the BlinkM RGB LED connected
through I2C. Say Y to enable support for the BlinkM LED.
+config LEDS_MMIO
+ tristate Generic LED support for memory mapped peripherals
+ depends on LEDS_CLASS
+ depends on HAS_IOMEM
+ help
+ This option enables generic support for LEDs controlled via
+ memory mapped registers.
+
config LEDS_TRIGGERS
bool LED Trigger support
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 3fb9641..8e5d0c8 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_LEDS_RENESAS_TPU)+=
leds-renesas-tpu.o
obj-$(CONFIG_LEDS_MAX8997) += leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
+obj-$(CONFIG_LEDS_MMIO)+= leds-mmio.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-mmio.c b/drivers/leds/leds-mmio.c
new file mode 100644
index 000..1ef0cda
--- /dev/null
+++ b/drivers/leds/leds-mmio.c
@@ -0,0 +1,250 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2012 ARM Limited
+ */
+
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/leds.h
+#include linux/mfd/core.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+
+static u32 mmio_led_read(void __iomem *reg, unsigned reg_size)
+{
+ switch (reg_size) {
+ case 32:
+ return readl(reg);
+ case 16:
+ return readw(reg);
+ case 8:
+ return readb(reg);
+ }
+ return 0;
+}
+
+static void mmio_led_write(void __iomem *reg, unsigned reg_size, u32 val)
+{
+ switch (reg_size) {
+ case 32:
+ writel(val, reg);
+ return;
+ case 16:
+ writew(val, reg);
+ return;
+ case 8:
+ writeb(val, reg);
+ return;
+ }
+}
+
+
+struct mmio_led {
+ struct led_classdev cdev;
+ spinlock_t *lock;
+ void __iomem *reg;
+ unsigned reg_size;
+ u32 off_and_mask, off_or_mask;
+ u32 on_and_mask, on_or_mask;
+};
+
+static void mmio_led_brightness_set(struct led_classdev *cdev,
+ enum led_brightness brightness)
+{
+ struct mmio_led *led = container_of(cdev, struct mmio_led, cdev);
+ unsigned long uninitialized_var(flags);
+ u32 val;
+
+ if (led-lock)
+ spin_lock_irqsave(led-lock, flags);
+
+ val = mmio_led_read(led-reg, led-reg_size);
+ if (brightness == LED_OFF) {
+ val = led-off_and_mask;
+ val |= led-off_or_mask;
+ } else {
+ val = led-on_and_mask;
+ val |= led-on_or_mask;
+ }
+ mmio_led_write(led-reg, led-reg_size, val);
+
+ if (led-lock)
+ spin_unlock_irqrestore(led-lock, flags);
+};
+
Re: [PATCH v2] ARM: S3C24XX: Add WIZnet W5300E01-ARM board support
On Mon, Sep 3, 2012 at 8:36 PM, Taehun Kim wrote:
> This patch adds WIZnet W5300E01 board changed to the new gpio functions.
> Please review this patch and apply it if do not have any problems.
>
> Signed-off-by: Taehun Kim
> ---
> arch/arm/mach-s3c24xx/Kconfig |5 +
> arch/arm/mach-s3c24xx/Makefile|1 +
> arch/arm/mach-s3c24xx/mach-w5300e01.c | 186
> +
> 3 files changed, 192 insertions(+)
> create mode 100644 arch/arm/mach-s3c24xx/mach-w5300e01.c
>
> diff --git a/arch/arm/mach-s3c24xx/Kconfig
> b/arch/arm/mach-s3c24xx/Kconfig
> index d56b0f7..94b60ca 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -248,6 +248,11 @@ config MACH_VR1000
> help
> Say Y here if you are using the Thorcom VR1000 board.
>
> +config MACH_W5300E01
> + bool "WIZnet W5300E01-ARM Board"
> + help
> + Say Y here if you are using the Wiznet W5300E01-ARM board.
> +
> endif # CPU_S3C2410
>
> config S3C2412_PM_SLEEP
> diff --git a/arch/arm/mach-s3c24xx/Makefile
> b/arch/arm/mach-s3c24xx/Makefile
> index 0ab6ab1..fc1a89e 100644
> --- a/arch/arm/mach-s3c24xx/Makefile
> +++ b/arch/arm/mach-s3c24xx/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_MACH_QT2410) += mach-qt2410.o
> obj-$(CONFIG_ARCH_SMDK2410)+= mach-smdk2410.o
> obj-$(CONFIG_MACH_TCT_HAMMER) += mach-tct_hammer.o
> obj-$(CONFIG_MACH_VR1000) += mach-vr1000.o
> +obj-$(CONFIG_MACH_W5300E01)+= mach-w5300e01.o
>
> obj-$(CONFIG_MACH_JIVE)+= mach-jive.o
> obj-$(CONFIG_MACH_SMDK2413)+= mach-smdk2413.o
> diff --git a/arch/arm/mach-s3c24xx/mach-w5300e01.c
> b/arch/arm/mach-s3c24xx/mach-w5300e01.c
> new file mode 100644
> index 000..7daf82e
> --- /dev/null
> +++ b/arch/arm/mach-s3c24xx/mach-w5300e01.c
> @@ -0,0 +1,186 @@
> +/* linux/arch/arm/mach-s3c24xx/mach-w5300e01.c
> + *
> + * Copyright (c) 2012 Taehun Kim
> + *
> + * For product information, visit http://www.wiznet.co.kr/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * @History:
> + * derived from linux/arch/arm/mach-s3c24xx/mach-bast.c, written by
> + * Ben Dooks
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static struct map_desc w5300e01_iodesc[] __initdata = {
> + /* Character LCD register map. */
> + { 0xf800, __phys_to_pfn(S3C2410_CS3), SZ_1M, MT_DEVICE }
> +};
> +
> +#define UCON S3C2410_UCON_DEFAULT
> +#define ULCON (S3C2410_LCON_CS8 | S3C2410_LCON_PNONE |
> S3C2410_LCON_STOPB)
> +#define UFCON (S3C2410_UFCON_RXTRIG8 | S3C2410_UFCON_FIFOMODE)
> +
> +static struct s3c2410_uartcfg w5300e01_uartcfgs[] __initdata = {
> + [0] = {
> + .hwport = 0,
> + .flags = 0,
> + .ucon = UCON,
> + .ulcon = ULCON,
> + .ufcon = UFCON,
> + },
> + [1] = {
> + .hwport = 1,
> + .flags = 0,
> + .ucon = UCON,
> + .ulcon = ULCON,
> + .ufcon = UFCON,
> + },
> + [2] = {
> + .hwport = 2,
> + .flags = 0,
> + .ucon = UCON,
> + .ulcon = ULCON,
> + .ufcon = UFCON,
> + }
> +};
> +
> +static struct mtd_partition w5300e01_mtd_partitions[] = {
> + [0] = {
> + .name = "Bootloader",
> + .size = 0x2,
> + .offset = 0,
> + .mask_flags = MTD_WRITEABLE,
> + },
> + [1] = {
> + .name = "Boot Param",
> + .size = 0x2,
> + .offset = MTDPART_OFS_APPEND,
> + },
> + [2] = {
> + .name = "Kernel",
> + .size = 0x3C,
> + .offset = MTDPART_OFS_APPEND,
> + },
> + [3] = {
> + .name = "Ramdisk",
> + .size = 0x100,
> + .offset = MTDPART_OFS_APPEND,
> + },
> + [4] = {
> + .name = "JFFS2 FileSystem",
> + .size = MTDPART_SIZ_FULL,
> + .offset = MTDPART_OFS_APPEND,
> + },
> +};
> +
> +static struct resource w5300_resources[] = {
> + [0] = {
> + .start = S3C2410_CS2,
> + .end= S3C2410_CS2 + SZ_1M,
> + .flags = IORESOURCE_MEM,
> +
Re: [PATCH] ARM: S3C24XX: Add WIZnet W5300E01-ARM board support
On Mon, Sep 3, 2012 at 9:20 AM, Taehun Kim wrote:
> This patch adds WIZnet W5300E01 board. I tested this code in the board.
> Please review this patch and apply it if do not have any problems.
Hi,
> Taehun kim
>
> Signed-off-by: Taehun Kim
> ---
> arch/arm/mach-s3c24xx/Kconfig |5 +
> arch/arm/mach-s3c24xx/Makefile|1 +
> arch/arm/mach-s3c24xx/mach-w5300e01.c | 186
> +
> 3 files changed, 192 insertions(+)
> create mode 100644 arch/arm/mach-s3c24xx/mach-w5300e01.c
>
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index d56b0f7..94b60ca 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -248,6 +248,11 @@ config MACH_VR1000
> help
> Say Y here if you are using the Thorcom VR1000 board.
>
> +config MACH_W5300E01
> + bool "WIZnet W5300E01-ARM Board"
> + help
> + Say Y here if you are using the Wiznet W5300E01-ARM board.
> +
> endif # CPU_S3C2410
>
> config S3C2412_PM_SLEEP
> diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
> index 0ab6ab1..fc1a89e 100644
> --- a/arch/arm/mach-s3c24xx/Makefile
> +++ b/arch/arm/mach-s3c24xx/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_MACH_QT2410) += mach-qt2410.o
> obj-$(CONFIG_ARCH_SMDK2410)+= mach-smdk2410.o
> obj-$(CONFIG_MACH_TCT_HAMMER) += mach-tct_hammer.o
> obj-$(CONFIG_MACH_VR1000) += mach-vr1000.o
> +obj-$(CONFIG_MACH_W5300E01)+= mach-w5300e01.o
>
> obj-$(CONFIG_MACH_JIVE)+= mach-jive.o
> obj-$(CONFIG_MACH_SMDK2413)+= mach-smdk2413.o
> diff --git a/arch/arm/mach-s3c24xx/mach-w5300e01.c
> b/arch/arm/mach-s3c24xx/mach-w5300e01.c
> new file mode 100644
> index 000..5ed79f5
> --- /dev/null
> +++ b/arch/arm/mach-s3c24xx/mach-w5300e01.c
> @@ -0,0 +1,186 @@
> +/* linux/arch/arm/mach-s3c24xx/mach-w5300e01.c
> + *
> + * Copyright (c) 2012 Taehun Kim
> + *
> + * For product information, visit http://www.wiznet.co.kr/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * @History:
> + * derived from linux/arch/arm/mach-s3c24xx/mach-bast.c, written by
> + * Ben Dooks
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static struct map_desc w5300e01_iodesc[] __initdata = {
> + /* Character LCD register map. */
> + { 0xf800, __phys_to_pfn(S3C2410_CS3), SZ_1M, MT_DEVICE }
> +};
> +
> +#define UCON S3C2410_UCON_DEFAULT
> +#define ULCON (S3C2410_LCON_CS8 | S3C2410_LCON_PNONE | S3C2410_LCON_STOPB)
> +#define UFCON (S3C2410_UFCON_RXTRIG8 | S3C2410_UFCON_FIFOMODE)
> +
> +static struct s3c2410_uartcfg w5300e01_uartcfgs[] __initdata = {
> + [0] = {
> + .hwport = 0,
> + .flags = 0,
> + .ucon= UCON,
> + .ulcon = ULCON,
> + .ufcon = UFCON,
> + },
> + [1] = {
> + .hwport = 1,
> + .flags = 0,
> + .ucon= UCON,
> + .ulcon = ULCON,
> + .ufcon = UFCON,
> + },
> + [2] = {
> + .hwport = 2,
> + .flags = 0,
> + .ucon= UCON,
> + .ulcon = ULCON,
> + .ufcon = UFCON,
> + }
> +};
> +
> +static struct mtd_partition w5300e01_mtd_partitions[] = {
> + [0] = {
> + .name = "Bootloader",
> + .size = 0x2,
> + .offset = 0,
> + .mask_flags = MTD_WRITEABLE,
> + },
> + [1] = {
> + .name = "Boot Param",
> + .size = 0x2,
> + .offset = MTDPART_OFS_APPEND,
> + },
> + [2] = {
> + .name = "Kernel",
> + .size = 0x3C,
> + .offset = MTDPART_OFS_APPEND,
> + },
> + [3] = {
> + .name = "Ramdisk",
> + .size = 0x100,
> + .offset = MTDPART_OFS_APPEND,
> + },
> + [4] = {
> + .name = "JFFS2 FileSystem",
> + .size = MTDPART_SIZ_FULL,
> + .offset = MTDPART_OFS_APPEND,
> + },
> +};
> +
> +static struct resource w5300_resources[] = {
> + [0] = {
> + .start = S3C2410_CS2,
> + .end= S3C2410_CS2 + SZ_1M,
> + .flags = IORESOURCE_MEM,
> + },
> + [1] = {
> +
Re: [PATCH] ARM: S3C24XX: Add WIZnet W5300E01-ARM board support
On Mon, Sep 3, 2012 at 9:20 AM, Taehun Kim kth3...@gmail.com wrote:
This patch adds WIZnet W5300E01 board. I tested this code in the board.
Please review this patch and apply it if do not have any problems.
Hi,
Taehun kim
Signed-off-by: Taehun Kim kth3...@gmail.com
---
arch/arm/mach-s3c24xx/Kconfig |5 +
arch/arm/mach-s3c24xx/Makefile|1 +
arch/arm/mach-s3c24xx/mach-w5300e01.c | 186
+
3 files changed, 192 insertions(+)
create mode 100644 arch/arm/mach-s3c24xx/mach-w5300e01.c
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index d56b0f7..94b60ca 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -248,6 +248,11 @@ config MACH_VR1000
help
Say Y here if you are using the Thorcom VR1000 board.
+config MACH_W5300E01
+ bool WIZnet W5300E01-ARM Board
+ help
+ Say Y here if you are using the Wiznet W5300E01-ARM board.
+
endif # CPU_S3C2410
config S3C2412_PM_SLEEP
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 0ab6ab1..fc1a89e 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_MACH_QT2410) += mach-qt2410.o
obj-$(CONFIG_ARCH_SMDK2410)+= mach-smdk2410.o
obj-$(CONFIG_MACH_TCT_HAMMER) += mach-tct_hammer.o
obj-$(CONFIG_MACH_VR1000) += mach-vr1000.o
+obj-$(CONFIG_MACH_W5300E01)+= mach-w5300e01.o
obj-$(CONFIG_MACH_JIVE)+= mach-jive.o
obj-$(CONFIG_MACH_SMDK2413)+= mach-smdk2413.o
diff --git a/arch/arm/mach-s3c24xx/mach-w5300e01.c
b/arch/arm/mach-s3c24xx/mach-w5300e01.c
new file mode 100644
index 000..5ed79f5
--- /dev/null
+++ b/arch/arm/mach-s3c24xx/mach-w5300e01.c
@@ -0,0 +1,186 @@
+/* linux/arch/arm/mach-s3c24xx/mach-w5300e01.c
+ *
+ * Copyright (c) 2012 Taehun Kim kth3...@gmail.com
+ *
+ * For product information, visit http://www.wiznet.co.kr/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * @History:
+ * derived from linux/arch/arm/mach-s3c24xx/mach-bast.c, written by
+ * Ben Dooks b...@simtec.co.uk
+ */
+
+#include linux/kernel.h
+#include linux/types.h
+#include linux/interrupt.h
+#include linux/list.h
+#include linux/timer.h
+#include linux/init.h
+#include linux/serial_core.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/io.h
+#include linux/mtd/mtd.h
+#include linux/mtd/nand.h
+#include linux/mtd/map.h
+#include linux/mtd/partitions.h
+
+#include asm/mach/arch.h
+#include asm/mach/map.h
+#include asm/mach/irq.h
+#include asm/mach-types.h
+
+#include mach/regs-gpio.h
+#include plat/gpio-cfg.h
+#include plat/cpu.h
+#include plat/devs.h
+#include plat/regs-serial.h
+#include plat/nand.h
+#include plat/pm.h
+
+static struct map_desc w5300e01_iodesc[] __initdata = {
+ /* Character LCD register map. */
+ { 0xf800, __phys_to_pfn(S3C2410_CS3), SZ_1M, MT_DEVICE }
+};
+
+#define UCON S3C2410_UCON_DEFAULT
+#define ULCON (S3C2410_LCON_CS8 | S3C2410_LCON_PNONE | S3C2410_LCON_STOPB)
+#define UFCON (S3C2410_UFCON_RXTRIG8 | S3C2410_UFCON_FIFOMODE)
+
+static struct s3c2410_uartcfg w5300e01_uartcfgs[] __initdata = {
+ [0] = {
+ .hwport = 0,
+ .flags = 0,
+ .ucon= UCON,
+ .ulcon = ULCON,
+ .ufcon = UFCON,
+ },
+ [1] = {
+ .hwport = 1,
+ .flags = 0,
+ .ucon= UCON,
+ .ulcon = ULCON,
+ .ufcon = UFCON,
+ },
+ [2] = {
+ .hwport = 2,
+ .flags = 0,
+ .ucon= UCON,
+ .ulcon = ULCON,
+ .ufcon = UFCON,
+ }
+};
+
+static struct mtd_partition w5300e01_mtd_partitions[] = {
+ [0] = {
+ .name = Bootloader,
+ .size = 0x2,
+ .offset = 0,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [1] = {
+ .name = Boot Param,
+ .size = 0x2,
+ .offset = MTDPART_OFS_APPEND,
+ },
+ [2] = {
+ .name = Kernel,
+ .size = 0x3C,
+ .offset = MTDPART_OFS_APPEND,
+ },
+ [3] = {
+ .name = Ramdisk,
+ .size = 0x100,
+ .offset = MTDPART_OFS_APPEND,
+ },
+ [4] = {
+ .name = JFFS2 FileSystem,
+ .size = MTDPART_SIZ_FULL,
+ .offset = MTDPART_OFS_APPEND,
Re: [PATCH v2] ARM: S3C24XX: Add WIZnet W5300E01-ARM board support
On Mon, Sep 3, 2012 at 8:36 PM, Taehun Kim kth3...@gmail.com wrote:
This patch adds WIZnet W5300E01 board changed to the new gpio functions.
Please review this patch and apply it if do not have any problems.
Signed-off-by: Taehun Kim kth3...@gmail.com
---
arch/arm/mach-s3c24xx/Kconfig |5 +
arch/arm/mach-s3c24xx/Makefile|1 +
arch/arm/mach-s3c24xx/mach-w5300e01.c | 186
+
3 files changed, 192 insertions(+)
create mode 100644 arch/arm/mach-s3c24xx/mach-w5300e01.c
diff --git a/arch/arm/mach-s3c24xx/Kconfig
b/arch/arm/mach-s3c24xx/Kconfig
index d56b0f7..94b60ca 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -248,6 +248,11 @@ config MACH_VR1000
help
Say Y here if you are using the Thorcom VR1000 board.
+config MACH_W5300E01
+ bool WIZnet W5300E01-ARM Board
+ help
+ Say Y here if you are using the Wiznet W5300E01-ARM board.
+
endif # CPU_S3C2410
config S3C2412_PM_SLEEP
diff --git a/arch/arm/mach-s3c24xx/Makefile
b/arch/arm/mach-s3c24xx/Makefile
index 0ab6ab1..fc1a89e 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_MACH_QT2410) += mach-qt2410.o
obj-$(CONFIG_ARCH_SMDK2410)+= mach-smdk2410.o
obj-$(CONFIG_MACH_TCT_HAMMER) += mach-tct_hammer.o
obj-$(CONFIG_MACH_VR1000) += mach-vr1000.o
+obj-$(CONFIG_MACH_W5300E01)+= mach-w5300e01.o
obj-$(CONFIG_MACH_JIVE)+= mach-jive.o
obj-$(CONFIG_MACH_SMDK2413)+= mach-smdk2413.o
diff --git a/arch/arm/mach-s3c24xx/mach-w5300e01.c
b/arch/arm/mach-s3c24xx/mach-w5300e01.c
new file mode 100644
index 000..7daf82e
--- /dev/null
+++ b/arch/arm/mach-s3c24xx/mach-w5300e01.c
@@ -0,0 +1,186 @@
+/* linux/arch/arm/mach-s3c24xx/mach-w5300e01.c
+ *
+ * Copyright (c) 2012 Taehun Kim kth3...@gmail.com
+ *
+ * For product information, visit http://www.wiznet.co.kr/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * @History:
+ * derived from linux/arch/arm/mach-s3c24xx/mach-bast.c, written by
+ * Ben Dooks b...@simtec.co.uk
+ */
+
+#include linux/kernel.h
+#include linux/types.h
+#include linux/interrupt.h
+#include linux/list.h
+#include linux/timer.h
+#include linux/init.h
+#include linux/serial_core.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/io.h
+#include linux/mtd/mtd.h
+#include linux/mtd/nand.h
+#include linux/mtd/map.h
+#include linux/mtd/partitions.h
+
+#include asm/mach/arch.h
+#include asm/mach/map.h
+#include asm/mach/irq.h
+#include asm/mach-types.h
+
+#include mach/regs-gpio.h
+#include plat/gpio-cfg.h
+#include plat/cpu.h
+#include plat/devs.h
+#include plat/regs-serial.h
+#include plat/nand.h
+#include plat/pm.h
+
+static struct map_desc w5300e01_iodesc[] __initdata = {
+ /* Character LCD register map. */
+ { 0xf800, __phys_to_pfn(S3C2410_CS3), SZ_1M, MT_DEVICE }
+};
+
+#define UCON S3C2410_UCON_DEFAULT
+#define ULCON (S3C2410_LCON_CS8 | S3C2410_LCON_PNONE |
S3C2410_LCON_STOPB)
+#define UFCON (S3C2410_UFCON_RXTRIG8 | S3C2410_UFCON_FIFOMODE)
+
+static struct s3c2410_uartcfg w5300e01_uartcfgs[] __initdata = {
+ [0] = {
+ .hwport = 0,
+ .flags = 0,
+ .ucon = UCON,
+ .ulcon = ULCON,
+ .ufcon = UFCON,
+ },
+ [1] = {
+ .hwport = 1,
+ .flags = 0,
+ .ucon = UCON,
+ .ulcon = ULCON,
+ .ufcon = UFCON,
+ },
+ [2] = {
+ .hwport = 2,
+ .flags = 0,
+ .ucon = UCON,
+ .ulcon = ULCON,
+ .ufcon = UFCON,
+ }
+};
+
+static struct mtd_partition w5300e01_mtd_partitions[] = {
+ [0] = {
+ .name = Bootloader,
+ .size = 0x2,
+ .offset = 0,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [1] = {
+ .name = Boot Param,
+ .size = 0x2,
+ .offset = MTDPART_OFS_APPEND,
+ },
+ [2] = {
+ .name = Kernel,
+ .size = 0x3C,
+ .offset = MTDPART_OFS_APPEND,
+ },
+ [3] = {
+ .name = Ramdisk,
+ .size = 0x100,
+ .offset = MTDPART_OFS_APPEND,
+ },
+ [4] = {
+ .name = JFFS2 FileSystem,
+ .size = MTDPART_SIZ_FULL,
+
Re: Power: s3c_adc_battery.c backup battery query
On Wed, Aug 22, 2012 at 8:05 AM, anish kumar wrote:
> Hello,
Hi
> I am trying to write a generic batttery driver using IIO and I have
> one some below
> questions:
>
> Why do we have the representation of backup battery in this
> driver(s3c_adc_battery.c) and when does the
> s3c_adc_backup_bat_get_property function gets called?
Because backup battery differs a bit from main battery (for example,
it has no current monitoring capability).
Maybe it was not a good decision, as it's possible to handle it via
platform data info as you suggested.
> As I understand, it is as this:It is called when it is registered
> and when the user wants to know the backup battery status(sysfs)
> and we don't do a workqueue scheduling as it will consume more power.
>
> static struct s3c_adc_bat backup_bat = {
> .psy = {
> .name = "backup-battery",
> .type = POWER_SUPPLY_TYPE_BATTERY,
> .properties = s3c_adc_backup_bat_props,
> .num_properties = ARRAY_SIZE(s3c_adc_backup_bat_props),
> .get_property = s3c_adc_backup_bat_get_property,
> .use_for_apm= 1,
> },
> };
>
> I am stuck with mulitple *get_property callbacks.As we don't know how many
> batteries system has and consequently we don't know how many *get_property
> callbacks to be implemented.
>
> So below is my plan:
> What I am trying to do is to have a single callback(*get_property) and manage
> everything in this callback and will use the name of the psy to
> distinguish between
> the different batteries which system has and driver will receive this
> information using
> platform data.Hope it makes sense.
Just send a patch for review :)
Regards
Vasily
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Power: s3c_adc_battery.c backup battery query
On Wed, Aug 22, 2012 at 8:05 AM, anish kumar yesanishh...@gmail.com wrote:
Hello,
Hi
I am trying to write a generic batttery driver using IIO and I have
one some below
questions:
Why do we have the representation of backup battery in this
driver(s3c_adc_battery.c) and when does the
s3c_adc_backup_bat_get_property function gets called?
Because backup battery differs a bit from main battery (for example,
it has no current monitoring capability).
Maybe it was not a good decision, as it's possible to handle it via
platform data info as you suggested.
As I understand, it is as this:It is called when it is registered
and when the user wants to know the backup battery status(sysfs)
and we don't do a workqueue scheduling as it will consume more power.
static struct s3c_adc_bat backup_bat = {
.psy = {
.name = backup-battery,
.type = POWER_SUPPLY_TYPE_BATTERY,
.properties = s3c_adc_backup_bat_props,
.num_properties = ARRAY_SIZE(s3c_adc_backup_bat_props),
.get_property = s3c_adc_backup_bat_get_property,
.use_for_apm= 1,
},
};
I am stuck with mulitple *get_property callbacks.As we don't know how many
batteries system has and consequently we don't know how many *get_property
callbacks to be implemented.
So below is my plan:
What I am trying to do is to have a single callback(*get_property) and manage
everything in this callback and will use the name of the psy to
distinguish between
the different batteries which system has and driver will receive this
information using
platform data.Hope it makes sense.
Just send a patch for review :)
Regards
Vasily
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
